TypeScript's Native Port: What the 6.0-to-7.0 Bridge Actually Changes for Your Build

The headline number is real. Microsoft’s TypeScript 7.0 announcement reports type-checking the VS Code codebase dropping from 125.7 seconds to 10.6 seconds — an 11.9x speedup — with four other large codebases landing between 7.7x and 8.9x. Memory use fell 6% to 26%. Editor error detection in VS Code went from 17.5 seconds to under 1.3 seconds.

What that headline hides is where the migration work actually lives. Almost none of it is caused by the Go rewrite. The compiler’s observable behavior is close to unchanged; what changed is the configuration surface, and most of that changed in TypeScript 6.0, released four months earlier, in March 2026. Teams that treated 6.0 as a routine minor bump and skipped straight to 7.0 are the ones filing confused issues.

The two releases do different jobs

TypeScript 6.0 is the last release built on the JavaScript codebase. Its job was to move the ecosystem off configuration that the native port would not carry forward — deprecating loudly while a JS-based compiler was still around to emit the warnings.

TypeScript 7.0 is the Go port. Its job is speed. It also finishes the removals 6.0 warned about.

That split matters for sequencing. If you jump from 5.x to 7.0, every deprecation warning 6.0 would have shown you arrives instead as a hard error, all at once, from a compiler you have never run before. The failure mode is a wall of errors that look like the rewrite broke something, when they are almost entirely config drift the bridge release was designed to surface gradually.

Run 6.0 first, fix what it warns about, then move. That is the entire migration strategy for most codebases.

What 6.0 deprecated and 7.0 removed

The removals cluster around module and target settings that predate the ES module ecosystem:

• target: es5 — gone. ES5 output is no longer a supported target.
• module: amd, umd, systemjs, none — removed.
• moduleResolution: classic and node/node10 — removed; use nodenext or bundler.
• outFile — removed.
• downlevelIteration — removed.
• baseUrl — removed; use paths instead.
• esModuleInterop: false and allowSyntheticDefaultImports: false — no longer settable. Both behaviors are always on.
• alwaysStrict: false — no longer settable.
• The module keyword for namespace declarations — use namespace.
• assert on import attributes — use with.

TypeScript 6.0 accepts most of these under an "ignoreDeprecations": "6.0" escape hatch, which is the mechanism worth using deliberately: turn it off, collect the warnings, work the list, then turn the flag away permanently before upgrading.

The default changes will bite harder than the removals

Removals produce an error naming the option. Changed defaults produce errors somewhere else entirely, which is why they cost more debugging time.

TypeScript 6.0 and 7.0 ship these new defaults:

Two of these deserve specific attention.

types: [] stops the compiler from automatically pulling in every @types package it finds in node_modules. That auto-enumeration was a long-standing source of accidental global type pollution, and removing it is the right call — but it means a project that relied on ambient Node globals now needs "types": ["node"] written explicitly. The error you get is Cannot find name 'process', which reads like a broken dependency rather than a config default.

rootDir: . now defaults to the tsconfig’s own directory rather than being inferred from the input file set. Projects with sources under src/ and a tsconfig at the repo root will see their output directory structure shift unless they set "rootDir": "./src" explicitly. This one changes emit paths, so it can pass type-checking and still break a deploy.

Both are one-line fixes. Both are much cheaper to find while 6.0 is warning you than while 7.0 is failing you.

Behavioral changes that are not config

A small set of changes affect type-checking itself rather than options:

strict: true by default is the big one for older codebases — if the project was never strict, this is not a migration, it is a project. Set "strict": false explicitly in the same commit as the upgrade and treat strictness as separate work.

Template literal types now preserve Unicode code points, so an emoji counts as one unit rather than its UTF-16 surrogate pair. Any type-level string manipulation over non-BMP characters may produce different results.

JavaScript file support was overhauled. Values can no longer stand in for types, and Closure-style annotations, @enum, and postfix ! in JSDoc are no longer supported. Codebases type-checking .js files with allowJs and checkJs should budget real time here; this is the one area where the rewrite genuinely dropped functionality rather than relocating it.

stableTypeOrdering: true cannot be disabled. It makes union and intersection ordering deterministic, which is a correctness improvement, but it can change the text of error messages and inferred type displays — enough to break snapshot tests that assert on type output.

What 7.0 does not do yet

The gap that will decide your timeline is the API.

TypeScript 7.0 does not expose a stable programmatic API. Microsoft states a new and different API is expected in 7.1. Until then, anything that drives the compiler programmatically rather than through tsc is blocked — which includes template type-checking for Vue, Svelte, Astro, Angular, and MDX.

If your build depends on any of those, 7.0 is not a full migration target yet. It is a fast type-check you can run alongside the old one.

The bridge for that period is the @typescript/typescript6 compatibility package, which ships the 6.0 compiler as tsc6 for side-by-side installation. Tools like typescript-eslint that need the old API can keep using it while tsc itself runs native. That is a supported configuration, not a hack, and it is how most non-trivial repos will spend the next few releases.

A migration order that works

1. Upgrade to TypeScript 6.0 and set "ignoreDeprecations" off. Collect warnings.
2. Fix the module/target/resolution settings the warnings name. These are mechanical.
3. Add explicit types and rootDir entries. Verify emit paths, not just type-check results.
4. Pin strict to whatever it is today so the default flip is not bundled into the upgrade.
5. Check whether any tool in your pipeline uses the compiler API. If yes, plan for @typescript/typescript6 side-by-side and treat 7.1 as the real cutover.
6. Then upgrade to 7.0 and measure. If your type-check was not a bottleneck, the speedup buys CI time and editor responsiveness rather than developer throughput.

The 8x-to-12x figures are worth having. They are also the easy part — the compiler team did that work. What is left for the rest of us is a config cleanup that was overdue regardless of which language the compiler is written in.