Enable `--allowImportingTsExtensions` by default

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.

该 issue 未列出任何文件或测试。首先跟踪 TypeScript 如何处理 --allowImportingTsExtensions 选项及其默认配置，然后审查 issue 中链接的 TypeScript 6.0 配置提案。完成的标准是定义默认行为和显式 opt-out，并解决受影响工具的行为及兼容性问题。