I remember the first time I ran tsgo on a real project. Not a hello-world demo, not a contrived benchmark, but our actual production codebase. The kind with 1,200 TypeScript files, a tangled web of generics, and a build that takes long enough for me to make coffee.
Seven seconds. Down from 74.
I stared at the terminal for a moment, convinced something had gone wrong. Maybe it skipped type-checking. Maybe it bailed on some files. I ran it again with verbose output. Full type-check. All 1,200 files. Seven seconds.
That moment is when TypeScript 7.0 stopped being "an interesting Microsoft project" and became something I needed to prepare for seriously. If you write TypeScript professionally, you need to prepare for it too. This is the biggest change to the TypeScript ecosystem since the language was created.
What Happened and Why
TypeScript's compiler has always been written in TypeScript (technically, JavaScript that compiles itself). This was a deliberate choice by Anders Hejlsberg and the team back in 2012. Writing the compiler in its own language proved the language was capable and made it easy for the TypeScript community to contribute.
But self-hosting has a ceiling. JavaScript is single-threaded. It cannot share memory between workers efficiently. Its garbage collector adds unpredictable pauses. For small projects, none of this matters. For monorepos with tens of thousands of files, these limitations mean builds that take minutes, editor startup that takes 30 seconds, and IntelliSense that lags behind your typing.
Microsoft tried optimizing the existing compiler for years. They squeezed out improvements here and there. But the fundamental bottleneck was the runtime, not the algorithms. You cannot make a single-threaded JavaScript program do the work of a parallel native binary, no matter how clever your optimizations are.
So the TypeScript team made a bold decision: rewrite the entire compiler in Go. Not a partial port. Not a thin native wrapper around the existing JavaScript code. A full, ground-up reimplementation of the TypeScript compiler as a native binary.
They chose Go for pragmatic reasons. Go compiles to native code, has excellent concurrency primitives (goroutines and channels), manages memory efficiently, and has a simpler learning model than Rust or C++ for a team that was mostly coming from TypeScript/JavaScript backgrounds. The goal was not to pick the theoretically fastest language. It was to pick the language that would let the team ship a correct, fast compiler in a reasonable timeframe.
The project was codenamed "Corsa." The binary is called tsgo. And the results speak for themselves.
The Benchmarks Are Not Marketing
I am usually skeptical of benchmark numbers in announcement blog posts. They tend to cherry-pick the best case and bury the caveats. So I was pleasantly surprised that the TypeScript team published real-world numbers across a range of well-known projects.
Here are the type-checking benchmarks comparing TypeScript 6.0 (tsc) to TypeScript 7.0 (tsgo):
| Project | tsc (6.0) | tsgo (7.0) | Speedup |
|---|---|---|---|
| VS Code (1.5M lines) | 89.11s | 8.74s | 10.2x |
| Sentry | 133.08s | 16.25s | 8.19x |
| TypeORM | 15.80s | 1.06s | 9.88x |
| Playwright | 9.30s | 1.24s | 7.51x |
VS Code's own codebase, 1.5 million lines of TypeScript, went from a 77-second type-check down to 7.5 seconds. That is not a marginal improvement. That is a different experience entirely.
The memory improvements are equally significant: roughly 3x reduction in memory usage. For large projects that currently push Node.js to its heap limits during compilation, this alone removes a painful constraint.
And watch mode, the thing most developers actually use day-to-day, now uses native file-system events instead of polling. The result is sub-100ms restart times when a file changes. You save, and by the time your eyes move from the editor to the terminal, the build is done.
These are not theoretical numbers. Multiple teams are already running tsgo in their daily workflows. The TypeScript team reports that stability is going well, with many teams using Corsa without blocking issues.
TypeScript 6.0: The Bridge You Need to Cross First
Before you can think about TypeScript 7.0, you need to understand TypeScript 6.0. Microsoft shipped it on March 23, 2026, and it exists for one specific purpose: to prepare your codebase for the breaking changes coming in 7.0.
TypeScript 6.0 is the last major version built on the original JavaScript compiler. There will be no 6.1. The JavaScript codebase is done. All engineering effort is now focused on the native port.
What 6.0 does is introduce deprecation warnings for every feature that 7.0 will remove or change. If your project builds clean on TypeScript 6.0 with zero deprecation warnings, you are in good shape for the migration. If it does not, those warnings tell you exactly what to fix.
Think of TypeScript 6.0 as a migration assistant. It is not exciting on its own. It is the step that makes the next step possible.
What Breaks in TypeScript 7.0
Let me be direct about the breaking changes, because some of them will affect a lot of projects.
Strict Mode Is On by Default
This is the big one. TypeScript 7.0 enables --strict by default. That means noImplicitAny, strictNullChecks, strictFunctionTypes, and all the other strict flags are on unless you explicitly turn them off.
If your project already uses "strict": true in tsconfig.json, you are fine. Nothing changes for you.
If your project has strict mode off, or partially on, this will surface a large number of new type errors. These are not new bugs. They are existing issues that your compiler was configured to ignore. Fixing them is the right thing to do, but doing it as part of a compiler migration adds unnecessary risk. Turn strict mode on now, in TypeScript 5.x or 6.0, and fix the errors before 7.0 arrives.
ES5 Target Is Gone
TypeScript 7.0 drops support for --target es5. The minimum target is now ES2015 (ES6). If you are still targeting ES5, you need to decide whether your users actually need ES5 compatibility. In 2026, the answer is almost certainly no. Every modern browser, Node.js version, and runtime supports ES2015. If you have a genuine need for ES5 output, you will need a separate transpilation step (Babel or similar) after TypeScript compilation.
The default target in 7.0 is es2025, which is a sensible default for most projects.
baseUrl Is Removed
This one will hit a lot of projects. The --baseUrl flag, which many codebases use for path aliases like import { foo } from 'components/Foo', is gone in TypeScript 7.0.
The replacement is paths with explicit mappings in your tsconfig.json, or switching your moduleResolution to bundler (if you use a bundler like Vite or webpack) or nodenext (if you run in Node.js directly). The migration is usually straightforward, but if your project has hundreds of imports relying on baseUrl, it is worth doing the conversion now rather than during the 7.0 upgrade.
Legacy Module Resolution Is Gone
--moduleResolution node10 (the old node option) is removed. You need to use bundler, nodenext, or node18 instead.
This is a change that has been recommended for years. If you are still on node10 resolution, you are already in a configuration that does not match how modern tools resolve modules. The migration to bundler or nodenext is the right move regardless of TypeScript 7.0.
AMD, UMD, and SystemJS Output Removed
If you are still emitting AMD, UMD, or SystemJS modules, TypeScript 7.0 will not do that for you anymore. The supported module outputs are ESM and CommonJS. Given that the JavaScript ecosystem has firmly moved toward ESM, this is a reasonable cleanup. But if you have legacy build pipelines that depend on AMD or UMD output from TypeScript, plan your migration now.
Plugin API Changes
This is the one that affects tool authors more than application developers. The current TypeScript compiler plugin API will not work in 7.0. A new API is being built, but the surface area is not finalized yet. If you maintain a TypeScript language service plugin, transformer, or any tool that uses the TypeScript compiler API (think: custom linters, code generators, documentation tools), this is a significant concern.
The TypeScript team has acknowledged this and is working on a migration path, but "working on it" is not the same as "done." Keep an eye on the microsoft/typescript-go repository for updates.
The Practical Migration Path
Here is my recommended approach, based on what the TypeScript team suggests and what I have seen work.
Phase 1: Get to TypeScript 6.0
Upgrade your project to TypeScript 6.0 and enable the --deprecation flag. Fix every deprecation warning. This is the single most valuable preparation step because it surfaces exactly the issues 7.0 will enforce.
Specific things to address:
Enable strict mode if you have not already. Run
tsc --strictand work through the errors. This is the largest source of migration pain, and it has nothing to do with the Go rewrite. It is just good practice that 7.0 happens to enforce.Switch away from baseUrl for module resolution. Use explicit
pathsmappings or change yourmoduleResolutionstrategy.Update your target to at least ES2015. If you are targeting ES5, test whether your users actually need it. Drop it if you can.
Move off node10 module resolution. Switch to
bundlerif you use a build tool, ornodenextif you target Node.js directly.
Phase 2: Test With the Preview Compiler
The native preview compiler is available right now as @typescript/native-preview on npm. Install it and run tsgo alongside your existing tsc to compare results.
bun add -d @typescript/native-preview
npx tsgo --noEmit
Compare the output against tsc --noEmit. If both report the same errors (or tsgo reports no errors), you are in good shape. If tsgo surfaces new issues, fix them now while you still have the JavaScript compiler as a fallback.
The TypeScript team has run this comparison against 20,000 test cases and only 74 show differences. Your project will very likely produce identical results.
Phase 3: Migrate When 7.0 Ships
When TypeScript 7.0 hits stable (expected mid-to-late 2026), the migration should be straightforward if you did Phases 1 and 2. Update your typescript dependency, replace tsc with tsgo in your build scripts, and verify everything still works.
For most projects, this will be a version bump and nothing else. The breaking changes are all things you will have already addressed in Phase 1.
What This Means for the Ecosystem
The performance improvements in TypeScript 7.0 have ripple effects across the entire JavaScript development toolchain.
Editor Experience Transforms
VS Code's TypeScript integration, which powers IntelliSense, error highlighting, go-to-definition, rename, and find-all-references, is backed by the TypeScript language service. When that language service runs as a native binary instead of a Node.js process, every single editor operation gets faster.
The TypeScript team reports approximately 8x improvement in editor startup time. That means opening a large project and having IntelliSense work immediately, instead of waiting 15 to 30 seconds for the language service to index your codebase. For developers who open and close projects frequently, or who work across multiple repositories, this is a quality-of-life improvement that compounds throughout the day.
CI Pipelines Get Faster
If your CI pipeline runs tsc --noEmit as a type-checking step (and it should), that step just got 8 to 10x faster. For large projects where type-checking takes 2 to 3 minutes, that drops to 15 to 20 seconds. In a team that pushes 50 PRs a day, the cumulative time savings are significant.
This also means you can afford to run type-checking more often. Pre-commit hooks with type-checking become practical even for large codebases. The performance penalty that made developers skip type-checking in development effectively disappears.
Monorepos Benefit the Most
The biggest beneficiaries are large monorepos. TypeScript 7.0's Go runtime enables true parallel processing with shared-memory threads for multi-project builds. If your monorepo has 20 packages that depend on each other, tsgo can build independent packages in parallel instead of sequentially. This is where the 10x improvement is most impactful, because the current compiler cannot parallelize across project references at all.
What This Does Not Change
It is worth being clear about what stays the same.
The TypeScript language itself is unchanged. Every type, every feature, every piece of syntax you know works exactly the same. This is a compiler rewrite, not a language redesign. Your code does not need to change unless it was using deprecated features that should have been updated anyway.
Your tsconfig.json structure is the same. The configuration format is identical. tsgo reads the same tsconfig files with the same options (minus the removed ones).
Your development workflow is the same. You still write .ts files, you still get type errors, you still compile to JavaScript. The output is the same JavaScript. The types are the same types. Everything that made TypeScript TypeScript is still there. It just runs faster.
Type safety is identical. The Go compiler implements the same type-checking rules. The 20,000 test case comparison with only 74 differences (mostly edge cases in unfinished features) demonstrates that the rewrite is faithful to the original semantics. You are not trading correctness for speed.
The Bigger Picture
TypeScript has always been pragmatic. It did not try to replace JavaScript. It added a type system that made JavaScript more manageable at scale. It did not require special tooling from day one. It compiled to plain JavaScript that ran anywhere.
The Go rewrite follows the same philosophy. It is not changing what TypeScript is. It is removing a ceiling that limited how well TypeScript could serve large projects and fast development workflows. The teams building massive applications in TypeScript, the ones who felt the build time pain the most, are the ones who will benefit the most.
There is also a broader lesson here about pragmatic engineering. The TypeScript team could have rewritten in Rust for maximum theoretical performance. They chose Go because it let them ship a correct compiler faster. They could have kept optimizing the JavaScript compiler for another five years. They chose a clean break because the ceiling was the runtime, not the algorithms. These are the kinds of engineering decisions that move ecosystems forward.
If you are still on TypeScript 4.x or early 5.x, the migration path goes through 6.0 first. Get to 6.0, fix the deprecation warnings, test with the preview compiler, and you will be ready when 7.0 ships. The performance improvement alone is worth the effort, and the migration is designed to be incremental. You do not need to rewrite anything. You just need to stop using things that should have been updated years ago.
TypeScript just got ten times faster. That is not a marketing number. It is a measured reality across real-world projects. And for the millions of developers who build with TypeScript every day, it changes the feel of the entire development experience. Not what you build, but how fast every step of building it becomes.
That is the kind of improvement worth getting excited about.
Top comments (0)