Allow allowImportingTsExtensions: without either '--noEmit' or '--emitDeclarationOnly'

[commonpike]

🔍 Search Terms

allowImportingTsExtensions, allow importing ts extensions, emit, noEmit, emitDeclarationOnly, emit declaration only,

✅ 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

Note

Feature would have the user explicitly state they don't want valid JS (eg., as with omitting file extension completely, which is currently a valid syntax for emitting JS, and is more implicit) - Possibly would disagree with goal 4 of the design goals depending on the exact meaning of "clean, idomatic, recognisable". Note this is the same request as #53316

⭐ Suggestion

{
  "compilerOptions": {
    "allowImportingTsExtensions": "iKnowWhatImDoing"
  }
}

Without "moduleResolution": "bundler" and "noEmit": true

TypeScript will now happily emit JavaScript when using this option for allowImportingTsExtensions.

• true - permits the use of .ts extensions in import/export and requires noEmit or emitDeclarationOnly
• false - has no effect; disables this option
• "iKnowWhatImDoing" - permits the use of .ts extensions in import/export

📃 Motivating Example

tsc compiles just fine when the source has imports with .ts extensions and noEmit is false, except

• it warns about a bad tsconfig, because you apparently removed --noEmit which is required
• in the compiled output there are still .ts extensions refering to files that are now .js

We can easily fix the compiled output with some postprocessing (like, sed), using tsc for the compilation.
In this workflow, I am using not using a bundler to compile, and I want tsc to emit output. The only problem is the error message thrown by tsc.

💻 Use Cases

1. What do you want to use this for?

• use tsc to compile and afterwards manually postprocess the (invalid) output; without using a bundler
• in particular, properly use .ts extensions in imports in the source code when refering to .ts files

2. What shortcomings exist with current approaches?

• tsc reports an error in the config when allowImportingTsExtensions is true but noEmit is false
• using .js extensions in imports in the source code when refering to .ts files feels invalid

3. What workarounds are you using in the meantime?

Glad you asked :-)

I've set noEmit: true and moduleResolution: node in tsconfig.json, but from the command line (or package.json), I use

npx tsc && ( npx tsc --noEmit false 1>/dev/null || true ) && postProcessStuff

which effectively runs tsc once without output, if it succeeds runs it with output but surpressing the error and always return true, and then postprocesses the result.