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

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.

The Performance Numbers, With Receipts#

From Microsoft's announcement benchmarks, full build times on well-known open-source codebases:

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.
• downlevelIteration is 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".
• baseUrl is removed. Migrate paths mappings to be relative to the project root.
• The namespace module keyword (module Foo {}) is prohibited; use namespace.
• asserts on import statements is removed in favor of the standard with keyword.
• /// <reference no-default-lib /> directives are no longer recognized.

Options you can no longer turn off:

• esModuleInterop and allowSyntheticDefaultImports cannot be false.
• alwaysStrict is always on.
• stableTypeOrdering is permanently true.

Defaults that changed under you:

• strict now defaults to true.
• module defaults to "esnext" (was "commonjs").
• types defaults to [], so @types/* packages are no longer auto-included. If your globals (like process or describe) vanish, list them explicitly: "types": ["node", "jest"].
• rootDir defaults to "./" instead of being inferred, which changes output layout for projects that kept everything under src/.
• noUncheckedSideEffectImports defaults to true.

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 lands in 7.1, which Microsoft expects within 3 to 4 months.

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 typescript

Step 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/typescript6

Or 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? Microsoft says TypeScript 7.1, expected within 3 to 4 months of the 7.0 release, after which 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

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