Microsoft has done something that would have seemed unthinkable a few years ago: they’ve rewritten the TypeScript compiler in Go. Not a wrapper. Not a shim. A full, ground-up rewrite of one of the most widely used developer tools on the planet — and the performance gains are staggering.
For development teams that rely on TypeScript (and in 2026, that’s most of us), this isn’t just a curiosity. It’s a shift that demands attention and, quite likely, action.
TL;DR
- TypeScript 7 (codename “Project Corsa”) rewrites the compiler from JavaScript to Go, delivering up to 10x faster builds on large codebases
- TypeScript 6.0, released March 2026, is the final JavaScript-based version — it’s designed as a bridge to 7.0 with breaking default changes
- Teams that upgrade to 6.0 now will have a smooth path to 7.0; teams that wait will face two releases of breaking changes at once
- The new
tsgobinary can already be tested via@typescript/native-previewin a parallel CI job - Key breaking changes: strict mode on by default, ESNext module default, no auto-included
@types/*, ES5 target support dropped
What Actually Changed — and Why
Anders Hejlsberg, TypeScript’s creator, announced the Go rewrite in early 2026. The reasoning was pragmatic: the original JavaScript-based compiler had reached its performance ceiling. No amount of optimisation could overcome the fundamental overhead of running a complex compiler inside a JavaScript runtime.
Go was chosen not for ideology, but for practicality. The TypeScript compiler’s internal code structure — heavy use of discriminated unions, tree-walking, and immutable data — mapped almost directly to Go’s type system and concurrency model. Hejlsberg called it a “plug and play replacement”: functionally identical code, just dramatically faster.
The numbers back this up. VS Code’s 1.5 million lines of TypeScript now compile in 8.7 seconds instead of 89 seconds — a 10.2x speedup. The Sentry project dropped from 133 seconds to 16 seconds. Type checking alone is up to 30x faster, with 2.9x less memory usage.
For smaller projects under 100,000 lines, the gains are more modest — typically 2–5x. But even that means your CI pipeline’s TypeScript step finishes in a third of the time, and your editor’s language server starts in under two seconds instead of ten.
The Two-Release Migration Strategy
Microsoft has been unusually thoughtful about this transition. Rather than dropping a breaking compiler rewrite on millions of developers overnight, they’ve staged the migration across two releases:
TypeScript 6.0 (released March 2026) is the bridge. It’s the last version built on the JavaScript codebase, but its defaults have been deliberately aligned with 7.0’s behaviour. This means teams that upgrade to 6.0 and fix their build are already 90% of the way to 7.0 compatibility.
TypeScript 7.0 (the Go-native tsgo binary) will drop the legacy code entirely. Features deprecated in 6.0 will be fully removed, and the new compiler API will replace the old plugin system.
Breaking Changes You Cannot Ignore
TypeScript 6.0 changed nine default settings simultaneously. If your team upgrades without reviewing your tsconfig.json, expect a wall of red. Here’s what matters most:
Strict Mode Is Now the Default
Previously, strict was opt-in. Now it’s on by default, which flips on strictNullChecks, noImplicitAny, strictFunctionTypes, and everything else under the strict umbrella. If your codebase wasn’t already running in strict mode, you’ll see hundreds (potentially thousands) of new errors. This is the single biggest migration hurdle for most teams.
Module Default: CommonJS → ESNext
The default module setting has shifted from commonjs to esnext. If your project still uses require() calls or depends on CommonJS interop without explicit configuration, things will break. The fix is straightforward — explicitly set your module option — but you need to know it’s coming.
No More Auto-Included @types
Previously, TypeScript automatically included every @types/* package in your node_modules. Now types defaults to an empty array. Nothing gets auto-included. If your code depends on ambient type declarations from DefinitelyTyped packages, you’ll need to explicitly list them in your config.
ES5 Target Support Is Gone in 7.0
The minimum target in TypeScript 7.0 is es2015. If you’re still targeting ES5 for legacy browser support, you’ll need a separate transpilation step or — more likely — it’s time to drop IE11 support entirely (which you should have done years ago, frankly).
What Your Team Should Do This Week
The teams that will have the smoothest transition are the ones acting now, not when 7.0 becomes the production default and everyone scrambles at once.
1. Upgrade to TypeScript 6.0
This is your staging ground. Fix every deprecation warning and resolve any errors from the new defaults. If you can build cleanly on 6.0, you’re in excellent shape for 7.0.
2. Add tsgo to Your CI Pipeline
Install @typescript/native-preview and run tsgo as a parallel check in CI. Don’t replace tsc yet — run them side by side and track error deltas. This gives you an early warning system for any behavioural differences between the two compilers.
3. Audit Your tsconfig.json
Make implicit settings explicit. If you’ve been relying on defaults for strict, module, target, or types, pin them to your intended values now. This insulates you from default changes across versions.
4. Check Your Plugin Dependencies
The current TypeScript compiler plugin API will not work in 7.0. Microsoft is building a new one, but if your build depends on custom transformer plugins, start tracking the microsoft/typescript-go repository for API updates.
5. Benchmark Your Build Times
Run tsgo on your codebase and measure the difference. This isn’t just a nice-to-have metric — it’s ammunition for the business case. If your CI pipeline’s TypeScript step drops from four minutes to forty seconds, that’s developer time reclaimed across every commit, every pull request, every day.
The Bigger Picture
TypeScript 7’s Go rewrite is part of a broader trend: the JavaScript ecosystem’s build toolchain is systematically being rewritten in faster, compiled languages. We’ve already seen this with Rust-powered tools like Biome, oxc, and Rspack replacing their JavaScript predecessors. Now the compiler itself has followed suit.
The implication is clear: the era of JavaScript tooling written in JavaScript is ending. What replaces it is faster, leaner, and — critically — doesn’t change how you write your application code. Your TypeScript stays the same. The tools that process it just stop being the bottleneck.
For development teams, this is unambiguously good news. Faster builds mean shorter feedback loops. Shorter feedback loops mean faster iteration. Faster iteration means shipping better software, sooner.
How REPTILEHAUS Can Help
If your team is navigating the TypeScript 6→7 transition — or any significant toolchain migration — we’ve been through this before. At REPTILEHAUS, we help development teams modernise their build pipelines, audit their configurations, and adopt new tooling without derailing ongoing product work. Whether it’s a half-day migration workshop or hands-on engineering support, get in touch and let’s make the transition painless.
📷 Photo by Pankaj Patel on Unsplash
