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.

[cmdcolin]

in my setup i am using rewriteRelativeImportExtensions: true, with allowImportingTsExtensions:true (not sure if that helps?? i was just stumbling on this because the error message "Option 'allowImportingTsExtensions' can only be used when either 'noEmit' or 'emitDeclarationOnly' is set." does not mention rewriteRelativeImportExtensions but it seems to fix it)

[RyanCavanaugh]

use tsc to compile and afterwards manually postprocess the (invalid) output; without using a bundler

We consider anything that has its own interpretation of module specifiers to be a bundler, so something that postprocesses the output names qualifies as that. To wit, we don't understand what the limitations of your processing are, and can't make any assumptions about what path transforms do/don't work in your setup.

What's wrong with using bundler mode in this scenario?

[commonpike]

allowImportingTsExtensions requires both noEmit and "moduleResolution": "bundler". Bundler is fine, you could argue the postprocessing that we do is a form of bundling. But before that, we are using tsc to create the output (using noEmit:false). This generates error messages and then actually works.

Please note rewriteRelativeImportExtensions: true that @cmdcolin mentions above might actually solve my particular use case, I haven't tried it yet. If it does, the error message shown at allowImportingTsExtensions should ideally mention that.

[RyanCavanaugh]

Correct; see #60397

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.