Deprecate, remove less-used `--module` targets (AMD, SystemJS, UMD)

[DanielRosenwasser]

For the sake of simplicity, TypeScript 7.0 will not implement support for the following --module options:

• amd
• umd
• systemjs

We believe most new code should use ECMAScript modules as that is the standard, as well as the common interface between bundlers and other tools. ECMAScript modules can largely serve the use-cases that these formats served, provided a mix of bundlers, import maps, or both).

In TypeScript 6.0, these options will be deprecated. TypeScript will issue an error if you use them unless you enable the ignoreDeprecations flag.

In TypeScript 7.0, the options will not be recognized, and the defaults will be --module esnext with --moduleResolution bundler.

[Renegade334]

Presumably allowUmdGlobalAccess should also go on the deprecation pile? It's not been mentioned so far.

Ditto for export as namespace ...?

[DanielRosenwasser]

Those are technically independent of the module format. export as namespace is not a problem per se. Best I can tell, both have already been ported to TS 7.0.

https://github.com/microsoft/typescript-go/blob/16953b75a0d1521fe7e7e2cdd91ecbb3e2d732b2/internal/checker/checker.go#L1742-L1749

We could discuss it.

[jakebailey]

Yeah, I think both are unrelated to the targets, just since they both affect script (non-module file) behavior.

[robpalme]

and the defaults will be --module esnext with --moduleResolution bundler.

There is an issue tracking the change to the default --target: #62198

I don't see corresponding issues for the change to the default --moduleResolution. Please could we get one to enable discussion?

[jakebailey]

There is an issue tracking the change to the default --module: #62198

Unless I'm mistaken, that issue is for target? module is not mentioned.

[DanielRosenwasser]

@robpalme I've updated the language of #62206 slightly to talk about the default moduleResolution in 7.0. What do you think?

[robpalme]

Thank you, Daniel. The deprecations look good. I'd like to address only the new defaults, and here looks like the best place to do so.

---

There's an overarching question of what is the design intent of updating the various defaults? I'd suggest there are at least three coherent answers to choose from:

• Minimize the need for overrides
  • By choosing defaults that represent the modal choice for a specific option.
  • (Note that if this were the only goal, it might result in a total set of defaults that is not optimal for any specific use-case.)
• Match the loose/inferred project defaults
  • To ensure consistency when users add a tsconfig to a project without one.
• Make prioritized use-cases work with (close to) zero-config
  • And hopefully provide an easy grow-up path to other use-cases.
  • (This is Rob's preference.)

The most common use-cases to prioritize might include:

• Browsers, via direct ESM
• JS runtimes, starting with Node
• Further tooling, such as a bundler

The current suggested defaults for TS 6.0 of module:esnext specifically with moduleResolution:bundler result in the slightly odd situation of them not being ideal for standalone cases such as Node and Browsers. They fail to protect you from writing code that will error in standalone cases - which I infer from Ryan is undesirable. It implies that TypeScript will generally not be used by itself and instead the majority of TypeScript projects will need to be paired with additional tooling that can cope with resolving extensionless imports.

I would like to instead advocate for prioritizing Node (e.g. by defaulting to module:nodenext) on the basis of it being a more minimal and more compatible starting point. It means both Node and bundler users benefit from safety and simplicity.

Bundlers (or any higher level starter kit) generally already handle the job of initializing the tsconfig with bundler-optimized defaults meaning it's zero work for them to keep doing so. Vite's default project creator npm create vite@latest emits this tsconfig for Vanilla TS projects. Maybe 6 out of 16 options could go away with TS 6.0 defaults, but it will remain far from zero-config. Whereas Node is on the verge of zero-config.

Starting with Node-compatible defaults leads to a more logical grow-up story where tsconfig lets you add features gradually and safely with close to zero downside for bundlers. target:esnext is another excellent example of TS 6.0 defaults taking this approach.

[DanielRosenwasser]

I think one of the reasons we are drawn to --moduleResolution bundler is that many users are currently on --moduleResolution node10, which ignores exports. For many people using bundlers, this "just works". If users were to use nodenext, they might be broken due to us respecting CJS/ESM differences, but not know exactly why.

So we can discuss it again, but that's the rationale to the best of my memory.