rewriteRelativeImportExtensions & enforce consistent extensions

🔍 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.

Commencez par lire l’implémentation existante et les tests de rewriteRelativeImportExtensions, puis comparez son comportement avec allowImportingTsExtensions et le diagnostic TS5097. Définissez comment les imports relatifs en .js, .ts, .mts et .cts doivent être validés, et ajoutez des tests montrant que la nouvelle option rejette les imports qui ne se résolvent pas vers des fichiers source.