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.

[darksabrefr]

A new option enforceImportingTsExtensions ? Or the possibility to configure finely allowImportingTsExtensions with a list of choices like never (currently false), allow (currently true), enforce/strict (currently doesn't exist), instead of true/false ?

[darksabrefr]

Tying this behavior to moduleResolution: "nodenext" is nearly impossible, it would be a major breaking change, breaking every project using this moduleResolution option, that is probably the best choice for any serious lib projects. Moreover, it's not the meaning of this option. Its meaning is to ensure a module resolution that is compatible with Node after you built your TS code, not while running it in place, which is only a pretty new Node's feature.
erasableSyntaxOnly doesn't mean allowing TS features compatible or not with an arbitrary thing, its purpose is to allow only TS features and syntaxes that don't need a context (i.e. a tsconfig and/or TS source interpretation) to be stripped out in the process of transpilling the TS source to valid JS. This is about TS syntax, not files extensions.

[darksabrefr]

@aaronadamsCA it seems that you only need to run TS code in place and forget that it's not the only usage of TS. The suggestion here tries to cover wider usages, in particular, how to write and setup a single TS code base built via tsc to be distributed in form of .js (and potentially .d.ts) files, but also run in place directly with .ts sources via Node, in particular in the dev environment. You can't put away the build scenario, that is the most used at this time, only to satisfy your particular need.