TypeScript 7.0 Migration Notes: The 10x Speedup Is Real, But Not Everyone Can Board Yet

TypeScript 7.0 went GA on July 8. This is not a routine semver major — the compiler core has been ported from TypeScript/JavaScript to Go. Microsoft explicitly calls it a "port," not a "rewrite": the type-checking logic remains structurally identical to 6.0. The runtime just changed from Node.js to a native Go binary.

I ran the migration on a few projects and wanted to write up what actually happened. This is not a paraphrase of the official announcement. It's about where reality diverged from expectations, what broke, and what I'd recommend for different project scales.

The Numbers: Don't Just Memorize "10x"

The "10x faster" tagline covers several different measurements. Here are Microsoft's published full-build benchmarks across five standard codebases at default settings (4 checker threads):

Project	TS 6.0	TS 7.0	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

The actual range is 7.7x to 11.9x. Microsoft's "8x to 12x" characterization is fair. If you bump checker threads from 4 to 8 (--checkers 8), the VS Code repo drops further to 7.51s (16.7x), but that's a tuned configuration, not the out-of-box experience.

The VS Code team's own blog measured different things entirely: tsc --noEmit -p src/tsconfig.json on the main source went from 36s to 5s (~7x), and the full npm run watch across roughly 50 tsconfig projects went from ~80s to ~20s (~4x). Different commands, different scopes — don't average these into the GA benchmarks.

Memory also dropped across the board. VS Code went from 5.2GB to 4.2GB (-18%), Bluesky from 1.8GB to 1.3GB (-26%). Faster and leaner is a rare combo.

On my own ~120k-line Next.js project, tsc --noEmit dropped from 23s to 2.7s — roughly 8.5x. Editor diagnostics went from "time to grab water" to essentially real-time. The difference is more dramatic than it sounds. That old rhythm of "change code, watch the bottom-left spinner, wait for red squigglies" is effectively gone.

Editor Experience: The Most Noticeable Change

Command-line speed is great, but most people feel TypeScript performance through editor feedback. Microsoft provided one striking data point: opening a file in the VS Code repo and seeing the first error went from 17.5 seconds on TS 6 to under 1.3 seconds on TS 7 — over 13x faster.

Seventeen seconds is long enough to check your phone. One-point-three seconds is a blink.

Slack's engineers noted on Bluesky that they had essentially given up on local type-checking because the language server took too long to load — they relied entirely on CI. After upgrading, local loading dropped to a few seconds, merge-queue time fell by 40%, and CI type-checking went from 7.5 minutes to 1.25 minutes.

After about a week of using it, my experience is: I used to open a project and instinctively go do something else while it loaded. Now the wait is short enough that I don't plan around it. This is the kind of improvement you can't go back from.

Who Can't Board: The API Gap

This is the biggest caveat of this release, and the most important thing to know before you try. TypeScript 7.0 ships without a stable programmatic API. Microsoft says 7.1 is expected in 3-4 months with a new API.

What does that mean? Any tool that calls the TypeScript compiler API from code cannot upgrade. Specifically:

• Vue (vue-tsc)
• Svelte
• Astro
• MDX
• Angular template type-checking
• typescript-eslint
• ts-loader (Webpack)
• Various build-tool TypeScript plugins

These ecosystem tools are stuck on TS 6.0 for now. If you're on a Next.js or plain React project that just uses tsc for type-checking, you're fine. If you're in a Vue or Svelte project, your editor has to keep using the 6.0 language service.

Microsoft provides a compatibility escape hatch: the @typescript/typescript6 package, which ships the tsc6 binary and re-exports the TS 6.0 API. You can install TS 7.0 alongside this package — use tsc for 7.0 on the command line, and let your tooling keep using 6.0's API.

For Angular projects, Microsoft's suggestion is: run tsc with 7.0 on the command line for fast full-project error detection, and keep the editor on 6.0 for template type support. Two versions, separate responsibilities.

Migration in Practice: Don't Just Bump package.json

The instinct is npm install -D typescript@latest and call it a day. The correct approach is to separate CLI from API.

Step one, install the native CLI:

npm install -D typescript@7

This now points to the Go-compiled tsc binary from TS 7.0.

Step two, keep tooling on the TS 6.0 API:

npm install -D @typescript/typescript6

Then use npm aliases in package.json:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript7": "npm:typescript@^7.0.0"
  }
}

Now npx tsc defaults to 7.0, while tools that import from the typescript package (like typescript-eslint) stay on 6.0.

Step three, handle tsconfig default changes.

TS 7.0 inherits 6.0's default changes and hardens 6.0's deprecations into outright errors. If your project compiled cleanly under TS 6.0, there are no type-level changes. But watch for these:

• strict now defaults to true. If you had it off, you'll get a wave of type errors. Fix them under 6.0 first, then upgrade.
• types now defaults to [] — it no longer auto-includes all @types packages. If you relied on @types/node being available implicitly, you now need to list it explicitly in tsconfig.json.
• rootDir now defaults to "./" instead of being inferred. If your tsconfig.json is at the project root and your code is in src/, add "rootDir": "./src".
• target: "es5" is no longer supported.
• moduleResolution: "node" / "node10" are no longer supported. Use "nodenext" or "bundler".
• baseUrl is no longer supported. paths now resolves relative to the project root.
• esModuleInterop and allowSyntheticDefaultImports can no longer be set to false.

Additionally, JS file handling (allowJs / checkJs) has been reworked. Previously, TypeScript analyzed .js files with a pile of JSDoc conventions and Closure Compiler compatibility logic, leading to inconsistencies with .ts analysis. TS 7.0 rewrote JS support for more uniform behavior. A few impacts:

• You can no longer use a value directly in a type position; write typeof someValue instead.
• @enum is no longer specially recognized. Use @typedef + keyof instead.
• A bare ? is no longer a valid type. Use any instead.
• Closure-style function type syntax like function(string): void is gone. Use (s: string) => void.

If your project has a lot of JSDoc-annotated .js files, run a build under TS 6.0 first and check for warnings.

Is It Worth Migrating?

Plain React / Next.js / Node.js projects: Yes, and you can do it today. The benefits are concrete — tsc --noEmit is an order of magnitude faster, editor feedback is essentially real-time, and CI times drop visibly. The migration cost is mostly tsconfig adjustments and CLI/API splitting: half a day to one working day.

Vue / Svelte / Astro / MDX projects: You can't fully migrate yet. Wait for 7.1. You can install 7.0 on the command line for fast tsc --noEmit as a supplementary check while keeping the editor on 6.0. Not ideal, but you at least get fast CLI type-checking.

Large monorepos: It depends on build-toolchain complexity. If you depend heavily on TS API plugins (typescript-eslint, webpack plugins, etc.), pilot it on one or two sub-projects first. Get CI green before rolling out. Microsoft's internal teams (Loop, Office, PowerBI, Teams, Xbox) and external ones like Bloomberg, Canva, Figma, and Google all participated in pre-release testing with positive feedback — but they have dedicated infra teams for the adaptation work.

Closing

TypeScript 7.0 is a rare kind of upgrade — an order-of-magnitude performance improvement with type-checking logic held constant, making the migration risk relatively contained. But the "no API" constraint will block a significant portion of the ecosystem until 7.1. That's not a bug; it's a timeline tradeoff. The team chose to ship the CLI and editor experience first, with the API to follow.

For those who can use it: once the speed is there, you can't go back.