Handling explicit file extension (Node16 + NodeNext)

[JulesGuesnon]

Description

Hello again!

When tsconfig has "module": "node16" | "nodenext", all the imports and exports will end with .js even if it's importing a typescript file. See documentation

Solution

I guess it's either reading the tsconfig file to know how to handle imports and exports, or the easiest way of doing it: if an import with an explicit .js fails, it can fallback to trying to read the same file but with .ts

[kaleidawave]

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 https://github.com/kaleidawave/ezno/blob/0b5f6888c7915517b772822e2391594b5c424345/checker/src/lib.rs#L299-L312

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?

[JulesGuesnon]

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/*"]
}

[JulesGuesnon]

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

[kaleidawave]

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 👍

[kaleidawave]

Basic imports with and without extensions have been added, including from node_modules. I don't think this quite follows TSC behaviour, but works for now. There is a lot more to do to support proper importing and external packages but will leave that to different issues. Closing this for now.