TypeScript 7.0 Native Compiler: What Breaks, What Gets 10x Faster, and How to Migrate

TL;DR
TypeScript 7.0 native compiler migration guide - the full breaking-changes list, verified performance numbers, side-by-side installs and when to stay on 6.x.
Last updated: October 24, 2026
TypeScript 7.0 shipped with the compiler rewritten in Go, and the headline claims hold up against Microsoft's published numbers: full builds are typically 8 to 12x faster, memory usage drops 6 to 26%, and the new LSP-based language server crashes 60% less than 6.0's. But 7.0 is not a drop-in upgrade. Defaults got stricter, a long list of legacy options is gone entirely, and the programmatic API that half the ecosystem depends on does not ship until 7.1.
This is the decision guide: exactly what breaks, what you gain, the real commands to migrate, and the honest cases where you should stay on 6.x for now. We covered the launch-day news and community reaction in our TypeScript 7 release post; this post is the playbook.
All claims below are sourced from the official TypeScript 7.0 announcement and the 7.0 RC post on the Microsoft dev blog.
Update, October 24, 2026: Microsoft published the TypeScript 7.1 Beta on October 20 (npm install -D typescript@beta). It ships the programmatic API this guide says 7.0 lacks, split into entry points such as typescript/sync and typescript/async, plus a "content mappers" plugin point aimed at Vue, Svelte, Astro, MDX and Ember tooling. Microsoft says a release candidate follows in about a month, then the final release, so treat the API as beta until then. Every 7.0 number below was re-checked against the 7.0 announcement and still matches.
The Performance Numbers, With Receipts#
From Microsoft's announcement benchmarks, full build times on well-known open-source codebases:
| Project | TypeScript 6 | TypeScript 7 | Speedup |
|---|---|---|---|
| VS Code | 125.7s | 10.6s | 11.9x |
| Sentry | 139.8s | 15.7s | 8.9x |
| Bluesky | 24.3s | 2.8s | 8.7x |
| Playwright | 12.8s | 1.47s | 8.7x |
| tldraw | 11.2s | 1.46s | 7.7x |
Memory usage dropped on every codebase tested: 18% on VS Code, 26% on Bluesky, 11% on Playwright. And because the Go compiler uses shared-memory parallelism, you can push further with the new --checkers flag: at --checkers 8, Microsoft measured 16.7x on VS Code.
The editor numbers matter more day to day. Opening a file with errors in VS Code went from roughly 17.5 seconds to under 1.3 seconds. Production users back this up: Slack reported CI type-checking dropping from about 7.5 minutes to 1.25 and 40% of merge queue time eliminated, Canva saw error detection fall from 58s to 4.8s, and Microsoft's own News Services team claims 400 CI hours saved per month. All of these figures are from the official announcement, so treat them as vendor-reported, but the open-source table above is reproducible.
Our own experience matches. This site's build gate runs the native compiler (via the @typescript/native-preview package that predated the 7.0 release), and a full --noEmit typecheck of a mid-sized Next.js app went from coffee-break territory to fast enough to run before every commit without thinking about it. Once typechecking is nearly free, you stop batching it and start gating on it.
What Breaks: The Full List#
TypeScript 7 dropped compatibility ballast that had accumulated for a decade. Per the RC announcement, these are hard removals, not deprecation warnings:
Removed outright:
target: "es5"is unsupported. ES2015 is the floor.downlevelIterationis gone (it only existed for ES5 targets).module: "amd","umd","system", and"none"are removed. Use"esnext"and let a bundler handle legacy formats.moduleResolution: "node"/"node10"/"classic"are removed. Use"nodenext"or"bundler".baseUrlis removed. Migratepathsmappings to be relative to the project root.- The namespace
modulekeyword (module Foo {}) is prohibited; usenamespace. assertson import statements is removed in favor of the standardwithkeyword./// <reference no-default-lib />directives are no longer recognized.
Options you can no longer turn off:
esModuleInteropandallowSyntheticDefaultImportscannot befalse.alwaysStrictis always on.stableTypeOrderingis permanentlytrue.
Defaults that changed under you:
strictnow defaults totrue.moduledefaults to"esnext"(was"commonjs").typesdefaults to[], so@types/*packages are no longer auto-included. If your globals (likeprocessordescribe) vanish, list them explicitly:"types": ["node", "jest"].rootDirdefaults to"./"instead of being inferred, which changes output layout for projects that kept everything undersrc/.noUncheckedSideEffectImportsdefaults totrue.
JSDoc-typed JavaScript takes the biggest hit. The Go compiler aligns JSDoc analysis with TypeScript semantics: values can no longer stand in for types (use typeof), @enum is not recognized, postfix ! and Closure-style function syntax (function(string): void) are unsupported, and @class no longer creates constructors. If you maintain a large JS codebase typed via JSDoc, budget real time here. The full delta lives in the typescript-go CHANGES.md.
The API gap is the biggest ecosystem break. TypeScript 7.0 does not expose a stable programmatic API. Anything that imports the compiler as a library, including webpack loaders and template type-checking for Vue, Svelte, Astro, MDX, and Angular, must stay on 6.0 until the new API ships in 7.1. The 7.1 beta is out, and the final release is expected after a release candidate roughly a month later.
How to Migrate: Verified Commands#
These commands come straight from the official announcement and RC post.
Step 1: Install. TypeScript 7 ships as the regular typescript package:
npm install --save-dev typescriptStep 2: Fix your tsconfig for the new defaults. The two most common breaks are rootDir and types. If your source lives in src/, pin it back:
{
"compilerOptions": {
"rootDir": "./src"
},
"include": ["./src"]
}
And re-declare the global type packages you were silently getting for free:
{
"compilerOptions": {
"types": ["node", "jest"]
}
}
Step 3: Replace removed options. Swap moduleResolution: "node" for "bundler" (bundled apps) or "nodenext" (Node libraries), replace baseUrl-relative paths with project-root-relative ones, and delete downlevelIteration, target: "es5", and any AMD/UMD/System module settings.
Step 4: Run 6.0 side by side where you must. Microsoft publishes 6.0 under a compatibility alias so tools that need the old API keep working:
npm install --save-dev typescript@npm:@typescript/typescript6Or pin both in package.json, giving the native compiler its own alias:
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
This layout keeps typescript resolving to 6.0 for API consumers (framework plugins, older editor tooling) while your CI typecheck runs the fast native binary. It is the same pattern this site used during the preview period, and it works: the fast compiler gates commits while nothing that imports the compiler breaks.
Step 5: Editor. VS Code users can install the TypeScript Native Preview extension; built-in support is rolling out, and Visual Studio 2026 enables TypeScript 7 automatically in compatible workspaces.
Step 6: Tune parallelism (optional). New flags: --checkers <n> sets type-checking workers (default 4), --builders <n> parallelizes project-reference builds, and --singleThreaded disables parallelism entirely for debugging or constrained CI runners.
When to Stay on 6.x#
Staying put is the right call, for now, if any of these apply:
- You depend on the compiler API. Vue, Svelte, Astro, or Angular template checking, custom webpack loaders, ts-morph-style codemods, anything that does
import ts from "typescript". Wait for 7.1 or use the side-by-side alias. - You still ship ES5. If you genuinely need
target: "es5"output from tsc, 7.0 cannot produce it. Either move transpilation to a bundler (esbuild, SWC, Babel) that can downlevel, or stay on 6.x. - You have a large JSDoc-typed JS codebase. The JSDoc semantics changes are the most labor-intensive part of this migration and there is no codemod from Microsoft yet.
- Your config leans on removed options (
baseUrl, AMD/UMD output,moduleResolution: "node") and you cannot touch build infrastructure this quarter.
For everyone else, the calculus is simple: the migration is mostly a tsconfig edit, and the payoff is roughly 10x on every typecheck you run for the next several years. Microsoft validated the RC on multi-million-line codebases at Bloomberg, Canva, Figma, Google, Notion, Slack, and Vercel before shipping, so "wait for a point release" caution buys less than usual here.
FAQ#
Is TypeScript 7 backwards compatible with my code?#
Your TypeScript source almost certainly compiles unchanged; the port was written for bug-for-bug type-checking compatibility with 6.0. What breaks is configuration (removed and stricter-default compiler options) and tooling that imports the compiler as a library. Audit your tsconfig and your build plugins, not your application code.
Do I need to rewrite anything in Go?#
No. The compiler is implemented in Go, but it ships as a prebuilt binary through the same npm install -D typescript package. Your workflow, your tsconfig (minus removed options), and your editor integration all stay JavaScript-ecosystem native.
Can I run TypeScript 6 and 7 in the same repo?#
Yes, and Microsoft explicitly supports it via npm aliases: keep typescript pointing at npm:@typescript/typescript6 for API consumers and add the native compiler under a second alias like @typescript/native. Details in the announcement.
When does the programmatic API arrive?#
TypeScript 7.1 Beta, with the new API, was published on October 20, 2026; Microsoft says a release candidate follows in about a month and the final release shortly after. After that the team returns to its usual cadence of feature releases every 3 to 4 months.
Is the 10x claim real or marketing?#
Both, in the sense that it is a real median. Published benchmarks range from 7.7x (tldraw) to 11.9x (VS Code) on full builds, higher with more checker workers, and lower-stakes wins like 13x faster error display in the editor. Your number depends on codebase size and CPU core count, since the gains come from native code plus shared-memory parallelism.
Does TypeScript 7 change my emitted JavaScript?#
The emit pipeline is ported faithfully, but ES5 output is gone and module now defaults to esnext. If you relied on tsc for CommonJS or ES5 output, set module explicitly or move downleveling to your bundler.
Continue Reading#
- How Bun Coordinated 64 Concurrent Claude Agents to Port 535K Lines of Zig to Rust
- Claude Code's Official Plugin Marketplace Is Here - and It's Already at 23k Stars
- Bun - the runtime and toolchain, pricing, and alternatives on one page
- Best Free Developer Tools - more tooling worth adding to a TypeScript stack
Sources#
- Announcing TypeScript 7.0 (Microsoft)
- Announcing TypeScript 7.0 RC (Microsoft)
- typescript-go CHANGES.md (full behavioral diff)
- TypeScript 7 Beta enabled in Visual Studio 2026 18.6 Insiders
Get the next deep dive like this in your inbox
One email a week on TypeScript and the rest of the AI dev stack. Free.
Read next
TypeScript 7 Is Here: The Native Go Port Delivers 10x Faster Builds
TypeScript 7.0 ships a Go rewrite of the compiler with 8-12x build speedups and faster editors on large codebases. Benchmarks, why Go, and what changes.
6 min readThe TypeScript AI Agent Stack in Mid-2026: Mastra vs Vercel AI SDK vs OpenAI Agents SDK vs LangGraph.js
The TypeScript AI agent stack compared - Mastra, Vercel AI SDK, OpenAI Agents SDK and LangGraph.js, which layer each covers, and how to pick or combine them.
10 min read10 TypeScript Patterns Every AI Developer Should Know
The TypeScript patterns that show up in every AI project. Streaming responses, type-safe tool definitions, structured output, retry logic, and more.
10 min readNew here? Start with
Technical content at the intersection of AI and development. Building with AI agents, Claude Code, and modern dev tools - then showing you exactly how it works.








