By TypeScript rewrote its compiler in Go. Builds that took 125 seconds now take 10. The upgrade path looks deceptively simple. The ecosystem has a real hole — and Microsoft isn’t filling it until TypeScript 7.1.
TypeScript 7.0 shipped stable on July 8, 2026 under the same npm install -D typescript command you’ve always used. The speed gains are legitimate. The tooling gaps are also legitimate. Which side of that tradeoff lands on you depends entirely on your stack.
The 10x Is Real
Microsoft benchmarked TypeScript 7.0 against real codebases, not synthetic tests. The VS Code source went from 125.7 seconds to 10.6 seconds — an 11.9x improvement. Sentry: 8.9x. Bluesky: 8.7x. Playwright: 8.7x. The language server — the piece powering your editor autocompletion — now opens a file with a type error in 1.3 seconds where it previously took 17.5 seconds.
The reason this is possible at all comes down to two things Go gives you that JavaScript never could: ahead-of-time compilation to a native binary, and shared memory multithreading. The JavaScript runtime can only use one core for the type-checker. The Go port uses all of them. Memory usage dropped 18% on the VS Code codebase. Language server crashes are down 60%.
These are not marketing numbers. They come from the VS Code team’s own codebase, measured by the VS Code team, published before the stable release. The methodology is transparent and the codebases are public.
What Actually Breaks
Here’s what the announcement posts don’t lead with: typescript-eslint refuses to install alongside typescript@7. npm throws an ERESOLVE peer dependency error because typescript-eslint’s published peer range only allows TypeScript versions below 6.1.0. Try to install both and npm blocks you outright.
The cause is the missing programmatic API. TypeScript 7.0 ported the type-checker to Go but did not ship a new API surface for tools to hook into. The old JavaScript-based API is gone. typescript-eslint, ts-morph, ts-jest, and the Volar engine behind Vue, Svelte, and Astro template type-checking all depend on that API. ts-morph has the nastiest failure mode: it produces incorrect output without throwing an error — silently wrong results.
A stable new API is targeted for TypeScript 7.1, expected around October 2026. Microsoft described it as “a new and different API” — not a port of the old surface — meaning tools will need real updates, not just compatibility shims.
The Hacker News launch thread reached 719 points and 301 comments. The most upvoted comment was not celebrating the speed. It reproduced Microsoft’s benchmark table and asked how downstream build tools would be affected. The developer community’s center of gravity was the ecosystem gap, not the speedup.
Framework Support Right Now
- React / Next.js: Full support. Upgrade when ready.
- Vue, Svelte, Astro, MDX: Base type-checking works. Editor template type-checking requires 7.1.
- Angular: Investigating. Uses its own language service; timeline unclear.
Breaking Changes (Most Were Announced in 6.0)
TypeScript 7.0 takes everything deprecated in TypeScript 6.0 and turns it into a hard error. If you ran TypeScript 6.0 with zero warnings, TypeScript 7.0 compiles clean. If you’ve been suppressing warnings with ignoreDeprecations, that field no longer exists.
target: "ES5"— removed entirely. Use Babel for ES5 transpilation alongside TypeScript for type-checking only if you still need IE11 targets.moduleResolution: "node"/"node10"— removed. Replace with"nodenext"or"bundler".- AMD, UMD, and SystemJS module output — removed.
ignoreDeprecationstsconfig field — gone. Fix the actual problems.
How to Migrate: The Staged Approach
Do not jump straight to TypeScript 7 from an older version. The staged path is cleaner and safer:
# Step 1: Get clean on TS 6.x first
# Fix all deprecation warnings, remove ignoreDeprecations from tsconfig
# Step 2: Update tsconfig
# Remove target: "ES5", switch moduleResolution to "nodenext" or "bundler"
# Step 3: Install TS 7 (only if NOT using typescript-eslint)
npm install -D typescript@7
npx tsc --noEmit # fix remaining errors
# If you use ESLint: use the sidecar approach instead
npm install -D @typescript/native-preview
npx tsgo --noEmit # fast type-checking in CI without breaking ESLintThe sidecar approach gives you the CI speed benefit now — type checks run 10x faster — without breaking ESLint or any programmatic API-dependent tool. When 7.1 ships and typescript-eslint releases a compatible version, you do the full migration then.
The Bottom Line
TypeScript 7.0 is a genuinely impressive engineering achievement. Rewriting a production compiler in a different language, shipping under the same CLI, and landing 10x speed gains on real codebases is not a trivial accomplishment. The team earned this one.
But the correct response is not “upgrade immediately.” It’s: upgrade to TypeScript 6.x now, confirm you’re clean, add @typescript/native-preview for fast CI checks, and migrate fully when 7.1 ships. InfoQ’s coverage framed it well: this is a release you adopt in stages.
New project with no legacy toolchain? TypeScript 7.0 is the obvious call. Existing projects with typescript-eslint, ts-morph, or Volar-backed frameworks: clean up your 6.x tsconfig, run the native preview in CI for the speed win, and wait for October. The full release is TypeScript 7.1. This is the preview with production performance.
