TypeScript 7.0 RC Is Out: What Changed Since the Beta, and How to Actually Migrate

TypeScript 7.0 stopped being a promise and started being something you can actually run. The Release Candidate shipped June 18, 2026, and Microsoft’s own estimate puts stable GA about a month out. We covered the compiler rewrite when it was still benchmarks-on-preview-builds back in February; this is the update now that there’s a concrete build with a concrete benchmark and a concrete migration path. If you read our earlier piece on the Go-based compiler, this is what’s changed since then.

The number that matters

Forget the round “10x” headline for a second and look at the actual measurement Microsoft has published: VS Code’s own codebase, 1.5 million lines of TypeScript, went from a 77-second full type-check to 7.5 seconds on the Go-based compiler. That’s not a synthetic benchmark built to flatter the new engine. It’s one of the largest real TypeScript codebases that exists, checked start to finish, and it happens to land almost exactly at 10x.

The reason that number is worth trusting more than a marketing bullet point is that it’s reproducible and it’s the same yardstick the TypeScript team has used consistently since the March 2025 announcement. If your own project is smaller than VS Code, expect a similar multiple, not necessarily the same absolute seconds.

What actually shipped between beta and RC

The beta, announced April 21, 2026, established that the Go rewrite worked and was fast. The RC, two months later, is where the practical controls showed up:

• --checkers <n> sets how many parallel type-checker worker processes run during a build. On a multi-core CI runner, this is a direct lever between build time and CPU usage.
• --builders <n> controls how many project references build in parallel, which matters for monorepos that use TypeScript project references to split a large codebase into buildable units.
• Overlapping pipeline stages. Parsing, type-checking, and emitting no longer strictly wait on each other in sequence for every file. The compiler can start type-checking files that have already parsed while later files are still being parsed.

None of these are language features. They’re the reason the RC’s numbers are meaningfully better than the beta’s, and they’re also the first place a migration can go wrong, because the defaults for --checkers and --builders may not match what your current CI runner’s core count can actually support efficiently. A build script written assuming single-threaded tsc behavior might benefit from explicitly setting these rather than trusting the defaults on a shared CI runner with unpredictable core allocation.

Where 7.0 sits in the version timeline

TypeScript 6.0 shipped March 23, 2026, and it was deliberately the last release on the original JavaScript-based compiler, a bridge version so that language features and the compiler swap didn’t land in the same release. TypeScript 7.0 is the Go-based engine, internally Project Corsa, with the compiler binary named tsgo. The language itself hasn’t changed across this transition. What changed is the program that reads your .ts files and checks them.

That separation is worth restating because it’s the actual answer to “should I be worried about this upgrade”: no, in the sense that your code doesn’t change. Yes, in the sense that anything that talks to the compiler programmatically, rather than just running it as a CLI tool, needs a look before you flip the version in production.

A migration checklist that matches where things actually stand today

If you’re an application developer with no custom compiler tooling: pin the RC in a separate CI job (not your main pipeline yet) and run your full test suite and tsc --noEmit against it. Compare the wall-clock time to your current baseline; that’s the number you’ll want later to justify the upgrade to a skeptical teammate.

If you use TypeScript project references in a monorepo: try --builders explicitly set to your CI runner’s core count rather than leaving it at the default, and measure. Turborepo and Nx caching strategies that exist specifically to avoid re-running slow type-checks may need re-tuning once type-checking itself stops being the bottleneck.

If you maintain a build tool, codegen library, or lint integration that uses the TypeScript compiler API directly: this is the one group that should not treat this as a drop-in version bump. Check the TypeScript team’s compatibility tracker before testing against the RC, since the Go compiler’s programmatic surface is not identical to the JavaScript one.

If you’re deciding whether to wait for GA: there’s no strong reason to, for most application code. Microsoft has stated the RC is suitable for production evaluation. The cost of trying it in a side branch is a CI job’s worth of compute; the cost of waiting is a month of type-checks running 10x slower than they need to.

What hasn’t changed, and won’t

The Go rewrite is a compiler-implementation change, not a language change, and it’s worth being explicit about what it doesn’t fix. TypeScript’s structural type system still produces confusing error messages in the same places it always has. Template literal types are still expensive to resolve. There’s still no runtime type validation without a library like Zod. A faster compiler makes all of those experiences happen faster, it doesn’t make any of them go away.

The GA date, whenever it lands in the next several weeks, will be a version bump for almost everyone reading this. The useful thing to do between now and then isn’t waiting, it’s spending twenty minutes in a CI branch finding out what your specific codebase’s number looks like next to that 77-to-7.5-second benchmark.