TypeScript 7.0 in Practice: What Happens When Your Compiler Gets 10x Faster

On July 8, 2026, Microsoft shipped TypeScript 7.0. This isn't a major version stuffed with new syntax features — it's the entire compiler, ported from TypeScript to Go.

What that means in practice: npm install -D typescript now gives you a native Go binary instead of a JavaScript compiler running on Node.js.

Not a Rewrite, a Port

The TypeScript team's phrasing is precise: "methodically ported, not rewritten from scratch." They didn't redesign the type checker in Go. They translated the TS 6.0 type-checking logic line by line. The inference behavior, error messages, and all the edge cases you've memorized should behave identically to 6.0.

Microsoft validated this against roughly 20,000 test cases accumulated over a decade. Out of all of them, only 74 produced different errors between TS 7 and TS 6 — and most of those were intentional behavioral changes, not bugs.

This isn't a "new compiler." It's the old compiler with a much faster engine.

The Numbers

Microsoft published five benchmark results at GA:

Project	TS 6	TS 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Bluesky	24.3s	2.8s	8.7x
Playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

VS Code's full type check went from over two minutes to just over ten seconds. That's not "faster" — that's type checking going from something you schedule to something you gate on every commit.

On my own mid-sized Next.js project, tsc --noEmit dropped from about 45 seconds to a steady 4-5 seconds. I used to push first and let CI catch type errors. Now running it locally is practically free.

Memory usage dropped too — between 6% and 26% depending on the project. If you run type checking in CI, lower peak memory means smaller (and cheaper) runners.

Editor Experience

Build times are a CI concern, but editor responsiveness hits you hundreds of times a day. TS 7's language service is also written in Go, communicating through the LSP protocol.

Loading the VS Code project in the editor went from 9.6 seconds to 1.2 seconds before the language service is ready. On my own project, red squiggles now appear almost instantly after opening a file — no more "switch tabs and come back" waiting.

Microsoft also claims TS 7's language server crashes over 20x less frequently than 6.0's. After a week of daily use, I haven't had a single language service crash, which used to happen occasionally on 6.x.

What Broke During Migration

Upgrading to 7.0 is not a version bump. TS 7 turns all 6.0 deprecations into hard errors and adopts stricter defaults.

strict is true by default

If you weren't using strict before, 7.0 will surface a wave of new type errors. The good news is these were errors you should have fixed anyway. The bad news is there might be a lot of them.

target can no longer be ES5

target: "es5" is a hard error. ES2015 is the new floor. If your project still compiles to ES5 for legacy browser support, you'll need to target at least ES2015 and let your bundler handle polyfills.

module options got trimmed

amd, umd, system, and none are all gone. Use esnext and let your bundler handle output formats. For the vast majority of projects this is a no-op — almost nobody was still using AMD.

moduleResolution cleanup

node, node10, and classic are removed, leaving only nodenext and bundler. This hits older projects harder, especially those whose paths config depends on baseUrl — because baseUrl is also gone. The fix is to make paths relative to the project root.

rootDir default changed

rootDir now defaults to ./. If your tsconfig.json lives at the project root but your source is in src/, you'll need to explicitly set "rootDir": "./src".

types defaults to an empty array

types now defaults to [], meaning @types/* packages are no longer auto-included. If your project depends on global type declarations from @types/node, @types/jest, etc., you'll need to list them explicitly: "types": ["node", "jest"].

Who Can Upgrade Now, and Who Should Wait

Ready now:

• Projects using Next.js, Remix, Vite, or other modern frameworks — these typically don't depend on TS's programmatic API directly
• CI pipelines that run pure tsc --noEmit for type checking
• Projects already on strict: true
• Projects with no target: "es5" requirement

Wait for 7.1:

• Projects relying on typescript-eslint — it needs the programmatic API, which isn't stable in 7.0
• Vue, Svelte, and Angular template type-checking — their compilers call TS APIs directly
• Astro, MDX, and other toolchains that use TS APIs for type processing
• Any plugin or tool that does import typescript from "typescript"

Microsoft's solution is the @typescript/typescript6 compatibility package, which lets you install both 6.0 and 7.0 side by side. Use 7.0 for editor responsiveness, keep 6.0 for CI and tooling, and switch fully when 7.1 lands.

Why Go and Not Rust

This was the most-asked question when the port was announced in March 2025. Anders Hejlsberg's answer was pragmatic: the TypeScript compiler spends most of its time traversing AST graphs and doing type computations. This kind of work maps naturally to Go's programming model, and the coding style closely resembles the original TypeScript codebase. Go gives you native compilation, goroutines, and a garbage collector — exactly what a compiler needs — without the cognitive overhead of Rust's ownership system.

There's also a boring practical reason: Go code looks structurally similar to the existing TypeScript codebase, which made "porting" rather than "rewriting" feasible. Choosing Rust would likely have forced a redesign of large portions of the internal architecture, turning a one-year project into a multi-year one.

What This Upgrade Actually Means

The impact of TS 7.0 goes beyond "it's faster." When type checking goes from a scheduled step to a nearly invisible background task, the entire development workflow shifts:

• CI's tsc --noEmit goes from the slowest step to one that runs alongside linting and testing
• --watch mode becomes genuinely usable — previous watch modes struggled to keep up on large projects
• Editor type feedback latency drops to near-zero, changing the rhythm of how you write code
• Lower memory usage reduces costs for both local development and CI runners

For me, the most tangible change is this: I used to save a file and wait a second or two for red squiggles to appear. Now the squiggles are already there by the time I look. That kind of seamlessness is the best UX upgrade there is.

If you haven't upgraded yet, install the TypeScript Native Preview extension for VS Code. It gives you the 7.0 editing experience without touching your build pipeline.