rewriteRelativeImportExtensions & enforce consistent extensions

[darksabrefr]

🔍 Search Terms

"rewriteRelativeImportExtensions", "extensions"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

An option/param to enforce imports with relative paths to point to files existing in sources rather than in built files, in short, make imports only allowing .ts and not .js extensions when importing a Typescript file.

📃 Motivating Example

rewriteRelativeImportExtensions is a great new feature and it works well. It permits to create hybrid projects directly executed by recent nodejs versions, but also buildable by tsc for distributing them. But since we now have the possibility to use the .ts extensions in imports because they will be rewritten at compilation time, we still can continue to use the .js extensions in parallel, pointing to built files.
As everyone knows, nodejs requires relative imports to have an extension and to point to an existing file and so, extensions have to be .ts (or .mts/.cts) to import other Typescript files.
It would be probably great that Typescript gives us an error when using unreachable file in this context, like its quasi-exact opposite: TS5097: An import path can only end with a .ts extension when allowImportingTsExtensions is enabled when .ts extensions are not allowed by configs.

💻 Use Cases

1. What do you want to use this for?
   In projects where nodejs can be used for any reason (tests, various scripts) and where code have to be built to be distributed over npm or any other repository, to avoid detecting bad imports extensions at nodejs runtime and to keep a consistent code base.

2. What shortcomings exist with current approaches?
   Only its permittivity, allowing to use inconsistent imports styles, that may don't run in nodejs, without detecting them at coding time.

3. What workarounds are you using in the meantime?
   It's not a bug, there's no need of workarounds, only vigilance.

[RyanCavanaugh]

It seems like the only way you get in trouble with this is if you do "side-by-side" (e.g. no outDir) compilation, right? Otherwise a relative import of "./shouldHaveBeenDotTs.js" will fail immediately at runtime (when running .ts), since that JS file doesn't exist

[darksabrefr]

That's not exactly what I want to described (who can live with side-by-side compilation?!), but you're perfectly right when saying it will fail at runtime, there's no question about that. I try to described a check before the runtime.

The idea behind this is when you activate rewriteRelativeImportExtensions, you indirectly says to TS "hey, I will refer to source paths only in relative .ts and .js imports, and not more to built .js paths". Consequently, I think it's possible in this context for TS to check the physical existence of imported .ts and .js paths in the code base, and to raise an error when they don't exist, long time before the runtime. It can also permit to do this check in a tsc --noEmit command, useful in a CI pipeline for example.
Additionally, as tsc with rewriteRelativeImportExtensions supports indifferently .ts and .js, in a project with a shared code base between "run TS in place" and "built with tsc" modes, you may mix perfectly working traditional .js imports of Typescript files while they are not attained by a "run TS in place" parts of your project, with valid "run TS in place" mode imports.

It's a kind of code base import consistency and physical existence check where the file behind the given path have to exist, in short.