TypeScript Just Got Rewritten in Go — And Your 7-Minute Build Is About to Take 45 Seconds

#typescript #software #webdev #programming

TypeScript Just Freaked Up

Why TypeScript 7.0 is the biggest infrastructure change in the language's history, even though it doesn't add a single new keyword.

If you've spent the last few years watching your tsc --noEmit spinner while your coffee goes cold, TypeScript 7.0 is the release you've been waiting for without knowing it. Released on July 8, 2026, it isn't a feature update. It's a foundation swap the entire compiler and language server, ported from a self-hosted TypeScript codebase into native Go.

That distinction matters more than it sounds. TypeScript has always compiled itself: the tool that type-checks your code was written in the same language it checks. That self-hosting was elegant, but it also capped how fast the compiler could ever be, because JavaScript engines were never built for the kind of CPU-bound, single-threaded grinding a large-scale type-checker demands. TypeScript 7.0 breaks that ceiling by leaving JavaScript entirely for the compiler's internals, while your code, your .ts files, and your day-to-day workflow stay exactly the same.

The headline number is 8x to 12x faster full builds, achieved through native code execution and, for the first time, real shared-memory multithreading something the old architecture simply couldn't do. But the more interesting story is in the details: how the team pulled off a rewrite of this scale without breaking a decade of existing type-checking behavior, and what it took to get some of the biggest engineering orgs in the industry to trust it in production before the ink was even dry.

This wasn't a rewrite from a blank page, either. The Go codebase was ported line-by-line in structure and logic from the existing implementation, not reimagined from scratch which is precisely why teams with multi-million-line codebases could adopt early betas without their type-checking suddenly behaving differently. The team spent over a year validating this parity against a test suite built up across ten years of the language's evolution, plus pre-release testing inside real production codebases at Bloomberg, Canva, Figma, Google, Notion, Slack, Vercel, and Microsoft itself.

The tradeoff, at least for now: TypeScript 7.0 ships without a programmatic API. If your tooling reaches into the compiler directly think typescript-eslint or custom build plugins you'll need to keep TypeScript 6.0 installed alongside 7.0 for a while. The team built a compatibility package specifically to make that coexistence painless, which tells you they were thinking about ecosystem disruption as seriously as they were thinking about raw speed.

What's Releases New

A native Go compiler with the same semantics. The type-checking logic is structurally identical to 6.0 same rules, same edge cases, same errors just running as compiled native code instead of JavaScript on Node.

Shared-memory multithreading. This is the real unlock. TypeScript 7.0 spins up multiple type-checker workers that split your codebase and check it in parallel, using a new --checkers flag to control how many. Default is 4 workers; on a beefier CI machine, bumping it to 8 squeezes out even more speed, at the cost of more memory.

A dramatically more stable language server. Anyone who's had VS Code's TS server hang or crash on a large monorepo will care about this one: failing language server commands dropped by over 80%, and crashes dropped by over 60%, compared to TypeScript 6.0.

A side-by-side compatibility path. The new @typescript/typescript6 package ships a tsc6 binary and re-exports the old API, so tools that still need programmatic access to TypeScript 6.0 aren't left stranded while the ecosystem catches up.

LSP-native editor tooling. The TypeScript Native Preview extension runs on the Language Server Protocol, meaning the same performance gains show up not just in VS Code but in any LSP-compatible editor and even in tools like Copilot CLI.

Developers Opinion

The reaction has been loud, and mostly celebratory, but not without some sharp technical debate.

The performance numbers aren't just marketing copy they're showing up in production. Slack's engineering team reported that TypeScript 7 cut their CI type-checking time from roughly 7.5 minutes down to 1.25 minutes, and eliminated 40% of their merge queue wait time. Their local development experience had reportedly degraded to "almost unusable" under TypeScript 6 at their codebase's scale, forcing engineers to lean on CI instead of their own editor TypeScript 7 apparently made local type-checking viable again.

On community threads, the more technical debate isn't about speed nobody's arguing with 10x it's about the philosophical shift of moving away from self-hosting. One frequently echoed point: self-hosted compilers put evolutionary pressure on a language to become good at writing compilers, which isn't necessarily the same as being good at being used. Others pointed to Rust-based tooling rewrites elsewhere in the JS ecosystem (Astral's ruff and uv being the most cited comparison) as evidence that this migration pattern dropping the source language for something faster at systems-level work is becoming a broader trend, not a one-off.

There's also a practical thread worth flagging for teams mid-migration: editor integrations that still reference the old preview binary name (tsgo) need a small amount of manual reconciliation if you're running package managers like mise alongside project-local TypeScript installs. Minor, but worth knowing before you flip the switch on a team-wide upgrade.

New releases Matters for Developers

CI pipelines that currently gate merges on type-checking will see the most dramatic wins this is where Slack's 6x improvement came from.
Large monorepos where the language server used to choke get real local type-checking back, instead of developers disabling it and hoping CI catches problems.
Teams on CPU-heavy build servers can tune --checkers upward to trade memory for even more speed, which matters for larger CI runners.
Editor experience improves for everyone, immediately, just by installing the extension no code changes required, since semantics haven't shifted.
Anything depending on the compiler API (linters, codegen tools, custom build steps) should hold off on a hard cutover until 7.1 ships the new API, and lean on the 6.0 compatibility package in the meantime.

Feature Impact at a Glance

Conclusion: And My Take, After 5+ Years Building Production TypeScript

I've lost real hours of my life to a spinning TS server on a large Next.js monorepo, watching a laptop fan spin up just to tell me I forgot a semicolon three files deep. So I'll say this plainly: this is the release that finally treats build performance as a first-class product concern, not an afterthought fixed by "just add more skipLibCheck."

What I respect most isn't the 10x number vendors throw around big multipliers all the time. It's that the team chose fidelity over reinvention. A rewrite that changed type-checking behavior even slightly would have been a nightmare for every team with a decade of accumulated // @ts-ignore compromises. Porting the logic, not just the language, is the harder and more disciplined engineering choice, and it's the reason companies with multi-million-line codebases could trust it in production before most of us even heard about it.

The missing API is the one real friction point right now. If your team leans on typescript-eslint or custom compiler plugins, budget a little time for the 6.0/7.0 coexistence dance rather than assuming a clean drop-in upgrade it isn't one, yet. That said, for the vast majority of teams just running tsc in CI and using the language server in the editor, this is close to a free upgrade: same code, same errors, dramatically less waiting.

My honest recommendation: install the Native Preview extension today, let your team feel the editor speed difference for a week, then schedule the CI migration once you've confirmed your critical tooling has a 7.0-compatible path. The wait for a fast, stable TypeScript compiler is over the only real decision left is how quickly your team gets out of the queue.