TypeScript 7.0 is now officially available as a stable release, and this is one worth paying attention to.
Not because it introduces a flashy new syntax feature or another configuration option, but because it improves something developers feel every day: waiting.
The TypeScript compiler has been rewritten in Go. The goal is clear: take advantage of native code, multithreading, and better parallelization to make builds, type checking, and the editor experience much faster.
Microsoft says TypeScript 7 is usually between 8x and 12x faster on large projects. In some cases, with more parallelization, the results go even higher.
The Numbers Are Pretty Clear
Microsoft published benchmarks on several well-known open-source projects using TypeScript 7’s default configuration:
| Project | TypeScript 6 | TypeScript 7 | Speedup |
|---|---|---|---|
| vscode | 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 |
The VS Code result is especially impressive: a build that took more than two minutes now takes just over ten seconds.
And when increasing the number of workers with --checkers 8, VS Code goes down to 7.51 seconds, which is 16.7x faster than TypeScript 6.
Another interesting point is that this speedup does not seem to come with higher memory usage. In the projects Microsoft measured, memory usage actually went down, between 6% and 26% depending on the project.
The Biggest Difference May Be in the Editor
For me, the most important part is not just faster builds.
The real improvement is the feedback loop while coding.
TypeScript 7 also comes with a new language server based on LSP. In practice, the things we use all day should feel faster: autocomplete, real-time errors, type hovers, code navigation, find references, and more.
Microsoft gives a good example: in the VS Code repository, opening a file with an error used to take about 17.5 seconds before showing the first diagnostic. With TypeScript 7, it takes less than 1.3 seconds.
On a small project, that is nice.
On a large codebase or a monorepo, that can really change the way you work.
What Teams Are Seeing on Real Projects
TypeScript 7 is not only coming with internal benchmarks. Microsoft says this version has been tested for more than a year on large codebases, both inside and outside Microsoft.
Some of the companies mentioned include Slack, Canva, Figma, Vercel, Notion, Sentry, and Bloomberg, as well as Microsoft teams working on Teams, Office, PowerBI, and Xbox.
A few numbers stand out:
- Slack reportedly reduced type checking in CI from 7.5 minutes to 1.25 minutes.
- Canva went from 58 seconds to 4.8 seconds before seeing the first error in the editor.
- One Microsoft team reported saving around 400 hours of CI time per month.
- The new language server reduced failing commands by more than 80% and crashes by more than 60% compared to TypeScript 6.
These numbers matter most when you work on large projects. When type checking gets too slow, teams often push it to CI or run it less often. If TypeScript 7 makes it practical again during local development, that is a real productivity win.
Installation
To install TypeScript 7:
bash id="g4p2wc"
npm install -D typescript
Then run:
bash id="fkg78d"
npx tsc
By default, TypeScript 7 uses 4 workers for type checking. You can adjust this with --checkers:
bash id="kz618u"
npx tsc --checkers 8
Of course, this should be tested depending on your machine and your project. More workers can make builds faster, but they can also increase memory usage. On a powerful development machine, it is worth trying. On a limited CI runner, it is better to measure before changing anything globally.
The Main Thing to Watch
Not every part of the ecosystem can move to TypeScript 7 immediately.
TypeScript 7.0 does not yet expose a stable programmatic API. That API is expected in TypeScript 7.1.
This affects tools and frameworks that depend directly on TypeScript, such as Vue, Astro, Svelte, MDX, some Angular workflows, Volar, and typescript-eslint.
For those cases, Microsoft recommends running TypeScript 6 and TypeScript 7 side by side for now.
For example:
json id="nmbg7p"
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
The idea is simple: keep TypeScript 6 for tools that still need its API, and use TypeScript 7 where possible to benefit from the performance improvements.
My Take as a Developer
I find this release really interesting because it does not try to get attention with visible new features. Instead, it solves a very real problem: waiting.
Waiting for type checking to finish, waiting for the editor to show errors, waiting for CI to confirm something we would rather know locally… these small delays add up quickly on large projects.
TypeScript 7 does not change the way we write TypeScript overnight. But it can change how fast we work with TypeScript.
And for a tool that is so widely used in modern development, that is a big deal.
Congratulations to the TypeScript team for this work. Rewriting such a central compiler in Go is impressive, and I would not be surprised if it inspires other languages and development tools.
Source: Microsoft’s official announcement, “Announcing TypeScript 7.0”.
Originally published on jatniel.dev.
Top comments (0)