TypeScript 7.0 Hit GA: What Changed Since My Benchmark, and Who Should Still Wait

By Pashalis Laoutaris|September 12, 2026|Updated: September 12, 2026|Category: Developer Tools|8 min read

Back in August, I ran an independent 26-fixture benchmark against TypeScript 7’s native compiler while it was still labeled “native preview.” I found a real but workload-dependent speedup, not the flat “10x” headline. Since then, TypeScript 7.0 has officially reached general availability. This is a short follow-up on what actually shipped, and more importantly, what still hasn’t.

The GA Announcement
What Actually Got Faster
The Catch: No Stable API Yet
Who Should Upgrade Now
Who Should Wait
How This Affects My Own Benchmark
Frequently Asked Questions (FAQ)
Conclusion
References

1. The GA Announcement

TypeScript 7.0 hit general availability on July 8, 2026, a few months after the 7.0 beta and release candidate builds that I benchmarked. The core technical story hasn’t changed since my own testing. The compiler and language service were ported to Go, with the type-checking logic kept structurally identical to TypeScript 6, rather than rewritten from scratch. That distinction matters. It’s a faster implementation of the same rules, not a different type system.

Microsoft’s own flagship number: a full type-check of the VS Code codebase (roughly 1.5 million lines) dropped from 125.7 seconds on TypeScript 6 to 10.6 seconds on TypeScript 7. That’s an 11.9x speedup at default settings. It’s not an isolated cherry-picked case either. Microsoft’s own figures for other real-world projects land in a similar range: Sentry at 8.9x (139.8s to 15.7s), Bluesky at 8.7x (24.3s to 2.8s), Playwright at 8.7x (12.8s to 1.47s), and tldraw at 7.7x (11.2s to 1.46s). That’s a best-case, real-world-code range, and it lines up with what I found in my own benchmark. Real-world fixtures showed the largest gains, around 6x geomean in my testing, while adversarial synthetic patterns showed a smaller, still-real improvement.

2. What Actually Got Faster

Beyond raw compile speed, the GA release also focused on language server stability. My original benchmark didn’t measure this at all, since it was scoped to cold full builds. According to Microsoft’s own telemetry, published in the GA announcement, TypeScript 7.0’s language server reduced failing language server commands by over 80% and cut server crashes by over 60%, compared to TypeScript 6.0.

Maybe your main daily pain point with TypeScript hasn’t been tsc build times, but VS Code’s language server hanging or crashing on a large codebase. If so, this is arguably the more relevant number for you, even though it got far less headline attention than the compiler speedup.

3. The Catch: No Stable API Yet

Here’s the part that didn’t make most of the launch headlines: TypeScript 7.0 shipped without a stable programmatic API. Microsoft has said a new, different API is expected in TypeScript 7.1, not 7.0.

This isn’t a minor footnote. It means any tool that embeds TypeScript’s compiler API directly into its own logic, rather than just shelling out to tsc, cannot run on TypeScript 7.0 yet. That list includes:

typescript-eslint, which powers most ESLint-based type-aware linting rules
ts-jest, for running TypeScript tests through Jest
ts-morph, a common code-generation and refactoring library
Template type checkers used by frameworks like Vue, Svelte, and Astro (relevant to this very site, which is built on Astro)
Less commonly, webpack loaders and other build-tool integrations that import the TypeScript API directly rather than shelling out to tsc

Those tools are expected to wait for TypeScript 7.1, which Microsoft has signaled should arrive around October 2026, before they can support the native compiler at all.

There is an official interim workaround, described in Microsoft’s own GA announcement under “Running Side-by-Side with TypeScript 6.0.” Microsoft publishes a compatibility package, @typescript/typescript6. It exposes the TypeScript 6.0 API and its own tsc6 binary, installed via an npm alias like npm install -D typescript@npm:@typescript/typescript6. That keeps your project’s typescript dependency pointed at the 6.0-compatible API, so anything that imports it, like typescript-eslint, keeps working. TypeScript 7 itself gets installed separately, and invoked explicitly for your actual build or type-check step. It’s a workable bridge, but it’s still a workaround. It doesn’t give you a unified toolchain, just a way to run both compilers side by side until 7.1 closes the gap.

4. Who Should Upgrade Now

Upgrade now if:

You only run tsc directly in CI or locally, with no ESLint type-aware rules, no ts-jest, and no framework-level template type-checking that depends on the TypeScript API.
Your bottleneck is genuinely full-build compile time on real application code, where the GA release shows its biggest, most consistent wins.
You want to test the new language server’s stability improvements on a non-critical branch first.

5. Who Should Wait

Wait for 7.1 if:

Your lint pipeline depends on typescript-eslint, which needs the new API before it can support TypeScript 7.
Your project is built with Astro, Vue, or Svelte and relies on their template type-checking, since all three sit on top of the same unstable API surface.
You run ts-jest or use ts-morph for code generation or refactoring tooling.

In practice, this covers a lot of real-world projects, including the one powering this site. Astro’s own type-checking pipeline depends on TypeScript’s API to validate .astro files. So this portfolio will stay on TypeScript 6 until 7.1 ships and Astro picks it up.

6. How This Affects My Own Benchmark

My original benchmark measured cold, full builds, with no incremental caching and no editor tooling involved. That was specifically to sidestep the API-stability question. Those numbers still hold: they measured tsc directly, not any tool built on top of the compiler API. What’s changed is the practical takeaway. In August, “the native compiler isn’t fully baked yet” was a reasonable caveat for anyone considering an early adoption. Now that 7.0 is GA, the more accurate caveat is narrower and more specific. The compiler itself is stable and safe to adopt for direct tsc usage, but the tools built around it are not, and won’t be until 7.1 ships.

7. Frequently Asked Questions (FAQ)

Is TypeScript 7.0 safe to use in production?

For direct compilation via tsc, yes, it’s officially GA. For any workflow that depends on ESLint’s type-aware rules, ts-jest, ts-morph, or a framework’s template type-checker (Vue, Svelte, Astro), no. Those tools need the new API expected in 7.1.

When is TypeScript 7.1 expected?

Microsoft has signaled a target of around October 2026, though exact dates for point releases can slip.

Does TypeScript 7 change how the type system behaves?

No. The Go port was a structural, line-by-line translation of the existing TypeScript 6 type-checking logic, not a redesign. The goal was speed, not new type-system behavior. Microsoft has been explicit that behavioral differences are considered bugs to fix, not intentional changes.

Why can’t tools like typescript-eslint just work on TypeScript 7 already?

Because they don’t just run tsc as a subprocess. They import TypeScript’s compiler API directly into their own JavaScript code, to walk the AST and type-check in-process. TypeScript 7.0’s Go-based implementation doesn’t expose a stable version of that API yet. So there’s nothing for those tools to import against.

Should I hold off upgrading my whole team to TypeScript 7?

If your team’s workflow includes ESLint type-aware linting, Jest via ts-jest, or an Astro/Vue/Svelte project, yes, wait for 7.1. If you only run tsc in CI with no dependent tooling, there’s no strong reason to wait.

Is there a way to use TypeScript 7’s speed without breaking my API-dependent tools?

Yes, as an interim step. Microsoft’s @typescript/typescript6 compatibility package lets you keep your linter and other API-dependent tools on TypeScript 6. Meanwhile, TypeScript 7 runs under a separate package alias for your actual build or type-check step. It’s more setup than a straight upgrade, and it’s meant as a bridge until 7.1 ships, not a permanent arrangement.

8. Conclusion

TypeScript 7.0’s GA release confirms what my own benchmark suggested back in August. The speedup is real, substantial on real-world code, and more modest on adversarial synthetic patterns, never a flat 10x. What the GA announcement adds is a much sharper picture of the adoption timeline. The compiler is ready. The ecosystem built around its API is not, and won’t be until 7.1 ships later this year. If you maintain a project with any dependency on TypeScript’s programmatic API, the right move right now is to wait. Not because the native compiler is unstable, but because the tools you actually run every day haven’t caught up to it yet.

9. References

Back to All Posts