Enable `--allowImportingTsExtensions` by default

[robpalme]

Acknowledgement

• I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

Comment

This is a pitch for another configuration change to go into TypeScript 6.0.

Background

TypeScript initially introduced a convention-based build step that converts *.ts source files into *.js executable files. To avoid needing to rewrite extensions during the build step, import specifiers in *.ts files could only reference other TypeScript files via *.js extensions. The compiler errored if you asked for a *.ts file. This static error was initially useful because it prevented the user from writing code that would later fail at runtime.

Over time, the world changed. Runtimes such as Deno, Bun, and Node (and more!) introduced built-in TypeScript support that could handle *.ts files directly. There was no need to have an internal concept of renaming the file to use a *.js extension. In fact, runtimes such as Deno and Node actively prevent the old convention of allowing folk to use *.js names to import a *.ts file.

Outside the runtimes, all modern tooling now understands how to resolve references to *.ts files. That includes widely-used bundlers such as Vite, ESBuild, Rollup, Turbopack, webpack, Parcel, RsPack. And it includes widely-used runtime loaders such as tsx and ts-node. Support for importing *.ts extensions is close to being universal.

In the browsers, ES Module resolution of relative imports is highly literal. You directly get what you ask for with no extension-guessing. Purists using a simplistic type-stripping compiler (ala ts-blank-space) need to use *.ts imports to be web-compatible whilst avoiding the complexities of extension rewriting.

The conclusion is that the world has flipped and importing *.ts has now become the most compatible choice.

Motivation

The set of default configuration changes being pitched for TypeScript 6.0 are excellent. They almost result in TypeScript being usable out-of-the-box with Node's built-in TypeScript support! The only true blocker remaining is --allowImportingTsExtensions.

Whilst it's true that Node users will benefit from other options such as verbatimModuleSyntax, rewriteRelativeImportExtensions, and module: nodenext rather than esnext, those could be considered DX enhancements. Whereas *.ts support is non-negotiable.

The minimum goal is to eliminate the verbosity of needing to specify this flag. A very similar but slightly more ambitious goal this contributes towards is to make Node usage frictionless.

Proposal

TypeScript 6.0 will assume that --allowImportingTsExtensions is on, unless explicitly disabled.

It seems unlikely this will be a breaking change so I can't think of any more advice to give on adoption.

Fallback Proposal

Depending on how the rest of TypeScript 6.0 config changes go, a next-best option would be to have implied defaults. For instance, if moduleResolution: bundler were the default, and that implied --allowImportingTsExtensions, then the goal of out-of-the-box Node usage would still be achieved.

Likewise if only module: nodenext implied --allowImportingTsExtensions that would still be helpful in reducing config fatigue, but would only hit the full goal if module: nodenext became the default.

Open Questions

How should tooling handle detection?

Potentially some tooling is already gating their own acceptance of *.ts by reaching into tsconfig and inspecting this flag. I'd suggest the way forward is to match TypeScript: to flip the default and continue to inspect tsconfig for the negative case.

So there may be some impact, but it is mostly business as usual for tooling to follow upstream TypeScript choices.

[RyanCavanaugh]

I agree with where you're coming from on the dev tools side of things, but probably 99% of JavaScript as executed is in the context of a browser where .ts imports aren't going to work without substantial help from the HTTP server. Having nodenext imply aITsE seems fine once more people have moved up to latest node, but having it be the default under esnext feels unjustifiable.

[robpalme]

Serving files named *.ts directly to the browser seems like a highly niche case and therefore should not be the focus of this issue. Apologies if that was distracting. @bakkot recently made a demo of that use-case so it came to mind. And as you say, it includes help from the HTTP server.

[bakkot]

Another option is to have this option be implied by --noEmit or --emitDeclarationOnly, since those imply either that the runtime is capable of executing TS directly or that transform to strip typescript types is going to be handled by some other tool (e.g. a bundler which is going to wrap everything up into a single file anyway).

[jakebailey]

I agree with where you're coming from on the dev tools side of things, but probably 99% of JavaScript as executed is in the context of a browser where .ts imports aren't going to work without substantial help from the HTTP server. Having nodenext imply aITsE seems fine once more people have moved up to latest node, but having it be the default under esnext feels unjustifiable.

Probably we would actually enable the extension rewriting flag, just to ensure nobody's actually publishing that code (which then implies the TS extension flag)

[jakebailey]

Another option is to have this option be implied by --noEmit or --emitDeclarationOnly, since those imply either that the runtime is capable of executing TS directly or that transform to strip typescript types is going to be handled by some other tool (e.g. a bundler which is going to wrap everything up into a single file anyway).

We typically don't do this, because we want the errors to be consistent whether or not emit was enabled, e.g. for quick checking things before full build.