Microsoft just shipped the Release Candidate for TypeScript 7, with the stable release expected next month. And the big deal, for once, isn't a new syntax or yet another config flag. It's that the entire compiler has been rewritten in Go.
Over the past year, the team ported the existing codebase (until now, TypeScript that compiled to JavaScript) to Go. It was done methodically from the current implementation, not rewritten from scratch, so the type-checking logic stays structurally identical to TypeScript 6. You don't change how you write TypeScript, you just get more speed.
Why it's so fast
The speedup isn't magic, it comes from the language. Go compiles to native code and takes advantage of parallelism through shared memory. The result Microsoft reports: builds that are often around 10 times faster than TypeScript 6. That number comes from their own measurements and from companies like Figma, Bloomberg, Vercel, Notion, and Slack, which have been testing pre-release builds for over a year and report similar gains.
And it doesn't stop at the tsc command line. The Language Server Protocol (LSP), the thing that powers autocomplete, type hovers, and real-time errors in your editor, runs on the same foundation. So the editor responds much faster, and that's probably what you'll feel most day to day on a large project.
The repo is open source (Apache 2.0, more than 25,000 stars on GitHub) and about 85% Go. For a project this size, and coming from Microsoft, betting on Go was not the obvious choice.
TypeScript 6, the step you shouldn't skip
TypeScript 7 inherits TypeScript 6's defaults, and anything deprecated in 6 now turns into a hard error. Since 6 is still recent, plenty of projects will need to adapt.
That's exactly what 6 is for: it doesn't bring big new features, it sets the stage. It warns you about the options and syntax that go away in 7. The team's advice, and mine: move to 6 first, clear those warnings, and the jump to 7 happens without surprises.
A few examples of what becomes a hard error in 7: target: es5, moduleResolution: node, baseUrl, or module: amd/umd/systemjs. On the defaults side, strict is now true and module is esnext. Two changes catch people off guard and are worth a look: rootDir now defaults to ./ (you'll often need to point it back to ./src), and types defaults to [], so you have to list your @types packages explicitly.
Running 6 and 7 side by side
Not all of your tools will be compatible with 7 overnight. typescript-eslint, for example, imports the typescript package directly, and the stable programmatic API won't land until TypeScript 7.1, a few months from now.
Microsoft set this up so the two versions can live together without stepping on each other. A compatibility package, @typescript/typescript6, ships a tsc6 binary and re-exports the 6 API. The trick is to use npm aliases in your package.json:
{
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.0",
"typescript-7": "npm:typescript@rc"
}
}
The typescript package your linter looks for actually points to 6, which is stable and what the tools expect, while npx tsc uses 7 for the rest of the project. It's a textbook parallel change: 6 keeps things tidy on linting, and 7 makes everything else faster. Tooling compatibility should settle down around 7.1.
Parallelization, checkers, and watch mode
TypeScript 7 parallelizes several steps: parsing, type-checking, and emit. Parsing and emit split easily across files. Type-checking is trickier because of dependencies between files, so the team spins up a fixed number of workers that share the work deterministically: same input files, same output results.
By default you get 4 workers, adjustable with --checkers. If you have more cores you can raise it, at the cost of more memory. On a tight CI runner, lower it instead.
There's also --builders, to build several projects in a monorepo at once. Watch out, the effect multiplies with --checkers: with --checkers 4 --builders 4 you can have up to 16 type-checkers running. And --singleThreaded forces a single thread, handy for debugging or for comparing 6 with 7.
Watch mode was rebuilt on top of Parcel's file watcher, also ported to Go. No more expensive polling over big node_modules folders, and file watching is much lighter.
Commands to try it
Install the RC:
npm install -D typescript@rc
Check the version:
npx tsc --version
# Version 7.0.1-rc
Compile like always, just faster:
npx tsc
Tune the number of type-checking workers:
npx tsc --checkers 8
Force a single thread to compare with 6:
npx tsc --singleThreaded
Install 6 and 7 at the same time with aliases:
npm install -D typescript@npm:@typescript/typescript6
npm install -D typescript-7@npm:typescript@rc
And to live on the nightlies:
npm install -D @typescript/native-preview
npx tsgo --version
The nightly binary is still called tsgo. Once 7 ships stable, everything moves back to the typescript package.
In short
TypeScript 7 doesn't touch your code or the typing rules, it goes after speed, both in the build and in the editor. The sensible plan: move to TypeScript 6 now to clear the warnings, test the RC in parallel on a real project, and report bugs on the microsoft/typescript-go repo. Stable lands next month.
Official announcement: Announcing TypeScript 7.0 RC.
Originally published on jatniel.dev.
