TypeScript 7 Just Went GA — Here's What Actually Changes for Your Build

Microsoft shipped TypeScript 7.0 as generally available on July 8, 2026, and if you've scrolled past the headline numbers without reading further, here's the one-line version: the entire compiler and language service was rewritten from scratch in Go, and it is not a small upgrade. Microsoft's own benchmark on the VS Code codebase — 1.5 million lines — showed type-checking drop from 125.7 seconds to 10.6 seconds. That's not a typo. That's an 11.9x speedup on a codebase most of us would consider massive.

I want to walk through what's actually different, what breaks, and what you should do about it this week — not in six months when your CI is already on fire.

Why Go, and why now

TypeScript has run on its own JavaScript-based compiler since 2012. As codebases scaled into the millions of lines, that compiler became the bottleneck everyone quietly tolerated — slow CI runs, laggy IntelliSense, editors that froze on large monorepos. The project, internally codenamed Project Corsa, ported the compiler to Go rather than rewriting it conceptually. Microsoft's team evaluated Rust but went with Go specifically because its structural similarity to the existing code allowed a near line-by-line port, and because goroutines made it straightforward to parallelize type-checking across CPU cores — something the old single-threaded compiler simply couldn't do.

That distinction matters: this is a port, not a redesign. The type-checking behavior and algorithms were deliberately preserved. Code that compiles cleanly under 6.0 should compile identically under 7.0, assuming you're not relying on the old compiler's programmatic API.

What actually breaks

Two things trip people up on upgrade:

1. 6.0's deprecations become hard errors. If you've been ignoring deprecation warnings, TypeScript 7 stops being polite about it.
2. No stable programmatic API yet. If your tooling — linters, custom build scripts, editor plugins — depends on tsc's internal API rather than just calling the CLI, you're stuck on 7.1 for now. Microsoft ships a compatibility binary alongside 7.0 specifically so API-dependent tooling can keep running on the legacy JS compiler while your builds move to the fast one.

The practical move most teams are making: point tsc and CI type-checks at the new native compiler immediately, and leave anything that touches the compiler API pinned to the legacy binary until 7.1 lands.

The part nobody's CI dashboard tells you

Here's the thing about a 10x build speedup — it's genuinely great, but it also exposes how much of your stack was quietly compensating for slow type-checking. Teams had added caching layers, split monorepos into smaller packages just to keep CI sane, or paid for beefier CI runners specifically to eat the type-check tax. A lot of that infrastructure is now dead weight, and dead weight on your stack usually means dead weight on your bill.

I ran this audit on my own setup last week: CI minutes down, so I dropped a tier on the runner, cut a caching step I no longer needed, and cross-checked a couple of paid add-ons against devtiers to see which ones had a free equivalent doing the same job. Ended up cutting two of them entirely.

Migration checklist

If you're planning the upgrade this sprint, here's the order that avoids surprises:

• Run npm install -D typescript@latest in a branch, not main
• Check for anything importing from typescript's internal API (search your repo for import * as ts from 'typescript' used beyond basic CLI wrapping)
• Fix deprecation warnings from 6.0 before you upgrade, not after — they're errors now
• Re-benchmark your CI type-check step and actually record the before/after numbers; you'll want them to justify downsizing runner specs
• If your CI is now finishing type-checks in seconds instead of minutes, revisit whether you still need whatever caching or parallelization hacks you built around the old bottleneck

For the benchmarking step, the TypeScript 7.0 release notes have the official flags for isolating type-check time from emit time — don't just eyeball your total CI duration, since bundling and tests will drown out the actual signal.

The bigger pattern

This is part of a broader shift happening across the JS tooling ecosystem — esbuild, swc, and now tsc itself moving compute-heavy work into native binaries instead of JavaScript. The interpreter tax that's been baked into JS tooling since forever is quietly getting removed, one tool at a time.

If TypeScript's compiler can get 10x faster without changing a single line of how you write code, it's worth assuming the rest of your stack has similar slack in it. devtiers is a decent starting point for that kind of pass — a searchable list instead of a stale blog post — but honestly any hour spent auditing your paid tools against what's changed in the last year tends to pay for itself.

Anyone already running 7.0 in production CI? Curious what your before/after numbers looked like — drop them below.