On July 8, 2026, Microsoft shipped TypeScript 7.0 — the first stable release of a compiler that was entirely rewritten in Go. I've been watching this project since it was announced, and having now had a week to dig through the benchmarks, the migration guide, and the real-world reports from teams who have already upgraded, I want to give you the clearest picture I can of what this actually means and whether you should move now or wait.
The short answer: if you're on React, Next.js, or a Node backend, move now. If you're on Vue, Svelte, Astro, or Angular templates, wait for 7.1. The reasons for both are specific and worth understanding.
Why This Is a Real Inflection Point
For fourteen years, the TypeScript compiler ran as a Node.js process executing TypeScript-compiled-to-JavaScript on V8. That sentence contains the whole problem. V8 is excellent at what it does, but it has three ceilings that no amount of engineering can lift: JavaScript execution is single-threaded by design, there's JIT warmup latency on every run, and memory is managed by a garbage collector that doesn't know your compilation graph. When Microsoft's compiler team profiled large codebases, these ceilings showed up as flat walls — you couldn't parallelize type-checking across files because the event loop wouldn't let you.
The Go rewrite, which Microsoft internally called Project Corsa and developed in the open at github.com/microsoft/typescript-go over fifteen months, removes all three ceilings at once. Go compiles to native machine code. There is no JIT warmup. And Go's goroutines make it straightforward to run type-checking workers in parallel across your project's files. The compiler now ships a --checkers flag that defaults to four parallel workers, a --builders flag for parallel project reference resolution in monorepos, and a --singleThreaded escape hatch if you need to debug resource usage or run in constrained CI environments.
The official announcement frames this as "typically 8x to 12x faster on full builds." Those numbers turn out to be conservative.
The Benchmarks, Taken Seriously
I don't trust vendor benchmarks that cherry-pick favorable conditions. What I trust are builds of codebases I recognize, run on hardware I understand. Microsoft published results from five real projects, and they hold up under scrutiny:
- VS Code (2.3 million lines): 125.7 seconds → 10.6 seconds — an 11.9x improvement
- Sentry: 139.8 seconds → 15.7 seconds (8.9x)
- Bluesky: 24.3 seconds → 2.8 seconds (8.7x)
- Playwright: 12.8 seconds → 1.47 seconds (8.7x)
- TLDraw: 11.2 seconds → 1.46 seconds (7.7x)
Memory is also down 6 to 26 percent across the tested codebases. Editor performance — how quickly VS Code can surface a type error after you change a file — went from 17.5 seconds to 1.3 seconds. That last number is the one that will change how your developers actually feel about working in the codebase day to day.
The teams that have already migrated are reporting operational results that match or exceed the benchmarks. Slack says they eliminated 40 percent of their merge queue time and cut CI type-checking from 7.5 minutes to 1.25 minutes. Microsoft's own News Services team is saving 400 hours per month in CI wait time. Canva cut editor error feedback from 58 seconds to 4.8 seconds. These aren't synthetic workloads — these are production engineering organizations reporting what changed in their daily workflow.
I've run large TypeScript monorepos since the early days of the language, and I can tell you that a 10x cut in type-check time is not a quality-of-life improvement. It's a workflow restructuring. When a full type-check takes two minutes, developers batch their changes. When it takes fifteen seconds, they check constantly. The feedback loop tightens in a way that actually affects how carefully people write code.
What Broke and Why It Matters
TypeScript 7.0 ships several breaking changes that are the result of years of deprecation runway finally reaching their end, and a few that are new constraints from the Go architecture. Understanding which is which matters for planning your migration.
The deprecation completions are largely painless for modern projects:
- ES5 target is gone. If your toolchain was still targeting ES5, it was already outdated — use Babel or esbuild for that transformation.
downlevelIterationis removed. Again, modern engines handle iterators natively.- AMD, UMD, and SystemJS module formats are removed. These haven't been meaningful targets for new projects in years.
baseUrlwithoutpathsis no longer supported. This one will catch more teams off guard — check yourtsconfig.jsonbefore you upgrade.strictis now enabled by default. If you've been deferring strict mode, 7.0 is the moment of reckoning.
The new architectural constraint is more interesting. TypeScript 7.0 does not yet expose a stable programmatic API. This is the decision that splits the ecosystem. Tools like Volar (which powers Vue's TypeScript integration), SvelteKit's template type-checker, Astro's IDE support, MDX, and Angular's template compiler all embed TypeScript via its programmatic API to analyze files the compiler itself doesn't parse — .vue files, .svelte files, JSX embedded in Markdown. None of them can switch to 7.0 until the new Go-based API surface stabilizes in TypeScript 7.1.
Who Should Upgrade Now vs. Who Should Wait
The line is clean: it's about whether your TypeScript integration runs through the CLI or through the programmatic API.
Upgrade now if you are using: React with Vite or webpack, Next.js (which already supports TypeScript 7.0 as of version 16.3), Node.js services, Deno, Bun, Express/Fastify APIs, or any project where tsc is your primary type-checking tool. For these teams, the migration path is install the new version, resolve the breaking changes listed above (most teams will hit the baseUrl and strict changes), and enjoy the speed.
Wait for TypeScript 7.1 if you are using: Vue 3 with Volar, Svelte, Astro, MDX, or Angular with template type-checking. The workaround Microsoft provides — running TypeScript 7.0 for CLI builds while keeping TypeScript 6 installed for your editor's language service — is functional but adds friction that isn't worth the complexity for most teams. TypeScript 7.1 is expected around October 2026, and the API work is already underway in the open.
What This Means for Build Infrastructure
I want to talk about the operational side of this for a moment, because the CI implications are significant and I haven't seen enough coverage of them.
If your CI pipeline currently runs TypeScript type-checking as a separate job — and if you're at any meaningful scale, it probably does — you are about to have a lot of headroom freed up. Teams that were running type-check jobs on 8-core or 16-core runners to parallelize at the project level are going to find that a single runner gets the job done in a fraction of the time, because the Go compiler does the parallelization internally via the --checkers workers.
That means you have a real decision to make about your CI topology. You can downsize runners and pocket the cost reduction. You can keep the same runners and run more checks in parallel — adding stricter lint passes, coverage thresholds, or integration tests that previously got cut for time. Or you can use the freed time to tighten merge gate SLAs, which is what Slack did. None of these are hypothetical benefits; they're straightforward consequences of a 10x time reduction on a step that was previously a bottleneck.
The --builders flag is worth particular attention if you're running a TypeScript monorepo with project references. Previously, building a tree of project references meant a sequential walk of the dependency graph: compile A, then B (which depends on A), then C (which depends on B and D), and so on. The new --builders mode runs independent branches of the dependency graph in parallel. For deeply layered monorepos — the kind where a shared utilities package sits below five separate service packages — this is where you're going to see the highest multiplier.
The Bigger Picture
I've watched a lot of infrastructure rewrites over the years. Most of them are announced with big numbers and deliver mixed results once teams actually migrate. This one is different because the performance gains follow directly from first principles: you took a single-threaded interpreted runtime and replaced it with a natively compiled concurrent one. The physics are just better. There isn't a workload where the Go version will be slower than the V8 version — the question is only how much faster.
What makes TypeScript 7.0 genuinely significant isn't just the speed. It's that the TypeScript team bet fifteen months of their roadmap on a full rewrite rather than incremental optimization, developed it entirely in the open, published every benchmark against real third-party codebases, and shipped with an honest accounting of what doesn't work yet. That's how infrastructure projects should be run.
The programmatic API gap for Vue and Svelte is real and shouldn't be minimized — those ecosystems represent tens of millions of developers who will need to wait. But Microsoft has been explicit about the 7.1 timeline and has provided workable bridge solutions. The trust is warranted here.
If you're on React, Next.js, Node, or any tsc-first stack: carve out a few hours this week, run your migration, resolve the breaking changes, and measure your build times before and after. The numbers won't disappoint you. If you're on Vue or Svelte: bookmark October 2026, follow the typescript-go repository, and start auditing your tsconfig.json for the deprecated options now so the 7.1 upgrade is a one-step process.
Fourteen years of building on a single-threaded JavaScript runtime. One rewrite in Go. This is what a generational tooling upgrade looks like.