A build can begin emitting newer JavaScript after a compiler upgrade even when the source did not change. TypeScript 6 makes the default target follow the current-year ECMAScript version, which is ES2025 at release time.

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

Pin target when reproducible output or older runtime support matters. Accept the default only when your runtime policy is evergreen and another build tool is responsible for final compatibility.

{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022"]
  }
}

what changed

The default target is now the most recent supported ECMAScript specification rather than an old fixed baseline. The default can therefore advance with future compiler versions.

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

Libraries, serverless runtimes, embedded browsers, and older LTS servers may parse or implement features differently. A bundler may transform syntax but cannot automatically polyfill every runtime API.

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. Write down supported runtime versions.
  2. Choose a target they can parse.
  3. Choose lib based on available globals.
  4. Test the emitted bundle on the oldest supported runtime.

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

the mistake to avoid

Do not assume target guarantees API availability. It controls emitted syntax transformations; runtime methods may still require a polyfill or a newer platform.

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

Inspect the emitted JavaScript for modern syntax and execute a smoke test under the oldest supported Node or browser environment.

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.