TypeScript 6.0 Upgrade Guide: The Last JavaScript Release

An earlier version of this post got the central fact wrong. It described TypeScript 6 as the Go rewrite and TypeScript 5.8 as the last JavaScript release. It’s the other way around: TypeScript 6.0 is the final release of the JavaScript-based compiler, and the Go port shipped as TypeScript 7. This is a rewrite as an upgrade guide for 6.0, with what it means for 7.

What is TypeScript 6.0?

TypeScript 6.0, announced March 23, 2026, is the last release built on the original JavaScript codebase. Most of its changes exist to prepare projects for TypeScript 7.0, the native compiler written in Go, which went GA on July 8, 2026. TypeScript 6.0 flips several tsconfig defaults and deprecates old options that 7.0 turns into hard errors.

The naming plan dates back to March 2025, when Anders Hejlsberg announced the native port and said the two lines would be called “TypeScript 6 (JS) and TypeScript 7 (native).” The 6.x line was meant to be maintained until 7 matures, and kept closely aligned with it.

Release timeline

Release	Date
Native port announced	March 11, 2025
TypeScript 6.0 beta	February 11, 2026 (npm)
TypeScript 6.0	March 23, 2026
TypeScript 6.0.3	April 16, 2026 (latest 6.x patch on npm)
TypeScript 7.0 RC	June 18, 2026 (npm)
TypeScript 7.0	July 8, 2026

One consequence catches people out. Since July, the latest tag on npm points at 7.x (7.0.2 as of October 2026). Running npm install -D typescript today installs TypeScript 7, not 6. If you want 6.0, ask for it:

npm install -D typescript@6

TypeScript 7.1 hasn’t shipped yet. The next tag is publishing 7.1 dev builds.

The new defaults in 6.0

These are the changes that break builds on upgrade, because they apply even if you never touch your tsconfig:

Option	Old default	6.0 default
strict	false	true
module	depended on target	esnext
target	es5	latest ES version (currently es2025)
noUncheckedSideEffectImports	false	true
libReplacement	true	false
rootDir	inferred from input files	the directory containing tsconfig.json
types	every @types package	[]

Two of these cause most of the upgrade noise.

The types change means @types/node, @types/jest and friends are no longer picked up automatically. The symptom is a flood of “Cannot find name ‘process’” or “Cannot find name ‘describe’” errors. List what you use, or set "types": ["*"] to get the 5.9 behavior back.

The rootDir change moves your output layout if you relied on inference. If dist/ suddenly contains a nested src/ folder, set rootDir explicitly.

strict: true by default only hurts projects that never set strict at all. If your tsconfig already says "strict": true, nothing changes. If it says nothing, you just turned on a lot of checks. Set "strict": false explicitly to keep the old behavior while you work through them.

What 6.0 deprecates

Deprecated options still work in 6.0 if you add "ignoreDeprecations": "6.0", but TypeScript 7.0 makes them hard errors. Treat that flag as a to-do list, not a fix.

• target: es5, and --downlevelIteration with it
• moduleResolution: node (also called node10). Use bundler, node16 or nodenext.
• moduleResolution: classic, which is removed outright
• module: amd, umd, systemjs and none, plus the amd-module directive
• baseUrl as a module lookup root. Use paths with relative entries, or subpath imports.
• esModuleInterop: false and allowSyntheticDefaultImports: false. Both are effectively always on now.
• alwaysStrict: false
• --outFile, which is removed
• the module keyword for namespaces (write namespace; declare module "x" still works)
• asserts on imports, including dynamic import() calls. Use with.
• /// <reference no-default-lib="true"/>

There’s also a CLI behavior change. Passing file names to tsc while a tsconfig.json exists in the directory is now an error (TS5112). Use the new --ignoreConfig flag if you really mean to compile specific files without the config.

A tsconfig that survives 6.0 and 7.0

For a modern app built with a bundler, a config like this has nothing deprecated in it:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "types": ["node"],
    "rootDir": "./src",
    "outDir": "./dist",
    "skipLibCheck": true,
    "paths": {
      "@/*": ["./src/*"]
    }
  },
  "include": ["src"]
}

For a Node library published without a bundler, use "module": "nodenext" and "moduleResolution": "nodenext" instead. Notice there’s no baseUrl. paths entries resolve relative to the tsconfig, which is what most people used baseUrl for anyway.

What’s new besides the cleanup

6.0 isn’t only removals. It adds:

• an es2025 value for target and lib, which includes RegExp.escape and moves Promise.try, iterator helpers and the new Set methods out of esnext
• built-in types for Temporal, available with --target esnext or "lib": ["esnext"]
• types for Map.prototype.getOrInsert and getOrInsertComputed
• support for #/ subpath imports under nodenext and bundler resolution
• the ability to combine --moduleResolution bundler with --module commonjs
• dom.iterable and dom.asynciterable folded into the dom lib

The final release also tightened checking of function expressions passed to generic calls. A few calls that inferred before may now need explicit type arguments. That’s the change most likely to produce genuinely new type errors in code that was fine on 5.9.

How 6.0 relates to 7.0

TypeScript 7.0 aims to match 6.0’s type-checking and command-line behavior. It adopts 6.0’s defaults and turns the deprecated options above into hard errors. So if your project compiles cleanly on 6.0 without ignoreDeprecations, the language-level migration to 7.0 is mostly done.

What you get for it is speed. The 7.0 announcement reports full-build times at default settings such as the VS Code codebase going from 125.7 seconds on TypeScript 6 to 10.6 seconds on 7 (11.9x), and Sentry going from 139.8 to 15.7 seconds. Microsoft describes typical full-build speedups as 8x to 12x. Those are the TypeScript team’s own measurements. Your numbers will depend on the codebase.

The catch is the compiler API. TypeScript 7.0 ships without one. Anything that imports typescript as a library (the 7.0 post names typescript-eslint as an example, and custom transformers or codegen scripts fall in the same bucket) can’t use 7.0’s compiler yet. The TypeScript team’s answer is to run both side by side.

The bridge is a compatibility package, @typescript/typescript6, which provides a tsc6 binary and re-exports the 6.0 API. The 7.0 post recommends npm aliases so tools that import typescript keep getting the 6.0 API while your builds use 7.0’s compiler. Its example:

npm install -D typescript@npm:@typescript/typescript6

Read that part of the 7.0 post before copying this into a monorepo, since how you wire the alias depends on which tools need the API and which package manager you use. The team says it expects 7.1 to ship “a new (and different) API,” and that feature releases will come every 3 to 4 months after 7.0. As of mid October 2026, 7.1 is still in dev builds.

For the 7.0 side of this, including who should wait, see our TypeScript 7.0 GA migration playbook.

An upgrade order that keeps CI green

1. Pin typescript@6 explicitly in package.json. Don’t let a latest or * range decide your major for you.
2. Run tsc --noEmit and fix what the new defaults surface. Start with types, then rootDir, then strictness.
3. Add "ignoreDeprecations": "6.0" only if you need to ship before the deprecations are fixed, and open a ticket to remove it.
4. Replace deprecated options one at a time: moduleResolution first (it changes how imports resolve), then baseUrl, then module formats and target.
5. Remove ignoreDeprecations and confirm a clean build.
6. Optionally run once with --stableTypeOrdering. It makes 6.0 order types the way 7.0 does, which helps you spot declaration-output or error-ordering differences before switching. The 6.0 post warns it can slow type-checking by up to 25%, so don’t leave it on.
7. When your tools are ready, move tsc to 7.0 and keep @typescript/typescript6 for anything that still needs the API.

The step people skip is the first one. Since npm install typescript now means 7.x, a fresh install or a latest range can move a project from 5.x to 7.x without anyone deciding to. Pinning is boring, and it prevents that particular surprise.