TypeScript 7.0 is 10x faster and written in Go. Here's how to adopt it without breaking CI.

Microsoft published the TypeScript 7.0 Release Candidate on June 18, 2026, and the headline isn't a new piece of syntax. It's the compiler itself. Over the past year the team ported TypeScript from its own bootstrapped JavaScript codebase into Go, and the result type-checks roughly 10 times faster than TypeScript 6.0. The published numbers are blunt: the VS Code codebase, about 1.5 million lines, drops from a 77.8-second type-check to 7.5 seconds. Sentry goes from 133 seconds to 16. Editor startup falls from around 9.6 seconds to 1.2, and memory use is roughly halved.

Two details matter more than the raw speed. First, this is a port, not a ground-up rewrite. The team moved the existing type-checking logic across to Go and kept the semantics, so 7.0 should enforce the same rules your code already passes under 6.0. Second, you install it like any other release, straight from the typescript package on npm. A stable release is planned for roughly a month out, and regressions go to the microsoft/typescript-go repository rather than the main TypeScript one.

So what does a 10x faster compiler actually buy a team? More than it first looks like.

The win isn't your laptop, it's CI

A faster editor is nice. Faster CI changes how people work. When we build cloud-native apps for enterprise clients on PHP and Docker, the type-check is usually one of the slowest gates in the pipeline, and it sits on the critical path for every single merge. Shaving a two-minute check down to fifteen seconds doesn't just save two minutes. It changes behavior. Developers stop batching changes to dodge the slow pipeline, reviewers get a green check while the context is still fresh, and the "I'll just merge and watch CI" habit that quietly breaks main starts to fade.

We've watched teams architect around slow tooling without realizing they were doing it: giant pull requests, skipped local checks, a --no-verify reflex on every commit. Most of that is a response to feedback that takes too long. Take the wait away and a lot of those habits lose their reason to exist.

A faster compiler is still a dependency change

Here's the part that gets lost in the excitement. Swapping your compiler for a binary written in a different language is a supply-chain decision, not a free win. During our pentesting and security review work, the build toolchain is one of the first places we look, because it runs with full access to your source and often your secrets, on every developer machine and every CI runner. A new tsc is exactly that kind of component.

None of this means the RC is risky to try. Microsoft has been running it on multi-million-line codebases inside and outside the company for over a year. It means you should adopt it on purpose: pin the exact version, read the changelog before you bump it, and don't let one engineer quietly swap the compiler for the whole team on a Friday afternoon.

What to do this week

Don't make 7.0 your blocking CI check yet. Add it next to the one you already have. Most CI systems let you run a second job that compiles with typescript@rc and reports its result without gating the merge. Run both for a couple of weeks, diff the errors, and you'll know exactly where 7.0 disagrees with your current build before it matters. Because it's a port rather than a rewrite, most teams find the diff is empty, but the few that hit an edge case will want to find it on their own schedule, not during a rushed upgrade after the stable release lands.

This pattern isn't specific to TypeScript. We use the same shadow approach across our web and mobile work whenever a core tool ships a major version. We stage an Xcode or Android Gradle Plugin bump in our native iOS and Android projects the same way, in a parallel job, long before it touches everyone's machine. The teams that get burned are usually the ones who read "the tests still pass" as proof that nothing changed. If you want a sense of how we run this in practice, our development work is built around exactly this kind of staged, low-drama upgrade.

If a slow pipeline that your team has quietly learned to work around sounds familiar, let's talk.