Handling explicit file extension (Node16 + NodeNext) about ezno HOT 4 OPEN

Hey!
After some investigation, it looks like the main use case of reading the tsconfig for type checking is only the module resolution (baseUrl is another example).
I don't know if it's the goal or not, but being able to run ezno against existing code base would be really nice, and without tsconfig I think it would be impossible.

Introducing it only for reading the compilerOptions.module would be nice imo. It's quite simple and straightforward to implement.
About the 2nd use case, Implementing Typescript alias system would be nice, but imo it would require to refactor the module resolution into another mod as it'll start to get bigger

from ezno.

Interesting. I had in plan to use oxc's resolver for files. I think it implements some of tsconfig parsing, so hopefully should have the same features of TSC.

For the moment I think adding checking for things like Promise and 'for loops' have priority before importing packages that use all those features, so will postpone this for now 👍

from ezno.

Interesting. This is one of the things I haven't looked at TSC's implementation. I should note Ezno does not currently read a tsconfig and doesn't have a lot of the same config.

The current relative importing logic looks at the path. If the path has an extension then it tries to read it directly. If it does not have an extension it looks for path.ts, then path.tsx and path.js until it gets a file

I haven't done a lot of investigation. Let me know if the current thing breaks or doesn't do quite the right thing under certain circumstances. If so maybe porting "module" from TypeScript's configuration might be needed?

from ezno.

Well imo this could be a good starting point to introduce reading the tsconfig. The module resolution is one use case, but another one would be to handle the aliases as for now it would break everything I think.
E.g:

"paths": {
    "@modules/*": ["src/modules/*"],
    "@services/*": ["src/services/*"]
}

from ezno.