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

ezno/checker/src/lib.rs

Lines 299 to 312 in 0b5f688

	let result = if full_importer.extension().is_some() {
	get_module(full_importer.clone(), environment, self)
	} else {
	let mut result = None;
	for ext in ["ts", "tsx", "js"] {
	full_importer.set_extension(ext);
	// TODO change parse options based on extension
	result = get_module(full_importer.clone(), environment, self);
	if result.is_some() {
	break;
	}
	}
	result
	};

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 👍