Some build pipelines resolve imports with bundler rules but still produce CommonJS for an older host. TypeScript previously rejected that pairing, even when another tool genuinely owned module resolution and transformation.

The useful question is not whether the release sounds modern. It is whether the changed default or capability affects the way your project installs, compiles, resolves modules, or runs in production.

Quick answer

TypeScript 6 permits moduleResolution: Bundler with module: CommonJS. Use it only when a bundler or transformer controls both resolution and final output; direct Node execution should use Node-shaped settings.

{
  "compilerOptions": {
    "module": "CommonJS",
    "moduleResolution": "Bundler"
  }
}

what changed

The compiler now accepts this combination, supporting mixed modern build pipelines without forcing their type checker to pretend Node resolves source imports directly.

This is a version-specific change. Pin the tool or runtime while migrating so a teammate and CI do not test a different contract by accident.

where teams will notice it

Test runners, plugin hosts, and legacy deployment environments may still require CommonJS even when source resolution depends on aliases or export conditions understood by a bundler.

A small smoke test is more useful than assuming the changelog covers your architecture. Reproduce the workflow from a clean checkout with the same command production uses.

a safe migration

  1. Name the tool that owns resolution.
  2. Inspect its final CommonJS output.
  3. Keep TypeScript in no-emit mode if another tool emits.
  4. Run output in the real host.

Change one resolution or security boundary at a time. That keeps failures attributable and makes rollback straightforward.

the mistake to avoid

Do not choose this pair as a general escape hatch for import errors. If tsc emits files run directly by Node, Bundler resolution can approve imports Node cannot find.

Avoid broad compatibility switches unless they are temporary, documented, and assigned a removal date. A migration that merely hides the warning will return as a harder TypeScript, Node, or npm upgrade later.

how to verify the result

Build through the actual bundler, inspect one transformed import, and execute the resulting artifact in the target CommonJS runtime.

Record the tool version and verification command in the pull request. That gives reviewers evidence and gives the next upgrade a known baseline.

rollout note

Ship the change in a small pull request that records the old behavior, the new behavior, and the rollback command. For an application, test the production image rather than only the developer machine. For a library, install the packed tarball in a tiny consumer project. Keep the previous lockfile or compiler configuration available until CI, deployment, and one real workflow have all passed.

That evidence makes the upgrade reviewable. It also prevents a later failure from being blamed vaguely on the entire major release when one setting or experimental flag was responsible.

official reference

Check the linked documentation again before upgrading production. Current-release features and announced security timelines can change in later patch releases.