It has been a year or so since Microsoft announced its plans to move TypeScript to a new, native runtime based on the Go language. Those first releases were unfinished (you had to compile them yourself) but showed promise, getting close to the expected 10x speed-up. That year has been one of steady progress, with Microsoft recently announcing the delivery of a release candidate build.
This release candidate is ready for use. It installs from npm like previous versions, and like earlier builds it works in much the same way as previous versions of TypeScript, checking types in your code, compiling it to run on ECMAScript-compliant JavaScript engines, and running just about anywhere. In addition, a native preview of the TypeScript language server for Visual Studio Code is available to help you write new TypeScript code and guide you through updating existing applications to the new language features.
All you need to do is enable the TypeScript 7 extension through the Visual Studio command palette and start coding. There’s a lot of work going on to get the new tooling ready for the final release of TypeScript 7, and new versions of the language server are being released almost daily. It’s certainly popular, too, with nearly half a million downloads at the time of writing.
What makes TypeScript 7 so much faster?
So how is this new TypeScript so much faster? Key to the improvements is a shift to a new native compiler built in Go. This has allowed the team to change how it operates, adding parallelization where possible. In some cases, this isn’t easy, such as when type checking large codebases split across many files.
Here TypeScript spawns a small number of checker workers that run across your codebase. They work independently, so can duplicate the work — though the output will be the same. You can choose your own number of checkers, but the more you use, the more memory and CPU will be required.
Large monorepos with many projects require a similar approach with independent builder workers. You’ll need to balance this with the number of checkers in use, as this can cause significant resource issues.
There are some significant language and configuration changes from TypeScript 5 (TypeScript 6 has the same changes, which makes it a useful tool for experimenting with migrations). It’s well worth reading the release candidate documentation to understand how these will affect your code, as well as using the TypeScript 7 extension for Visual Studio Code to identify where you need to make changes.
Working with users to build language tools
One important aspect to the development of TypeScript 7 has been collaboration with existing users of the language and its tooling, as well as using the existing suite of TypeScript test tools that have been used to evaluate other versions. As this update is primarily a port of existing code, rather than a bottom-up rewrite, the underlying language semantics and structure are the same as those used in the original JavaScript codebase, ensuring that code will quickly port from old to new versions.
A major internal collaborator was the Visual Studio Code team, who have been using TypeScript to develop the familiar cross-platform development tool. It’s an important partnership between tool and language, as VS Code is a key TypeScript development tool, hosting TypeScript’s language server and using its compiler to provide debugging and code completion features.
The VS Code team published a long blog post detailing how it has been working with the Go-based TypeScript. The team is both helping to develop the language and beginning the process of moving its codebase to the newer, faster, native platform.
How the VS Code team migrated is a useful case study, one that can help you move your TypeScript development more efficiently and with minimal risk. The team began working with extensions, using daily builds of TypeScript to ensure that bugs and issues could be reported as they occurred and would only have a limited impact as fixes could be rolled out quickly. At the same time, the VS Code team began using a preview version of the TypeScript 7 extension for VS Code, which was being built around the new compiler in parallel with its development.
Bridging development with TypeScript 6
The development of TypeScript 6 as a bridge between TypeScript 5 and TypeScript 7 allowed the VS Code team to transition to code that targeted a newer version of ECMAScript and provided more powerful checks. By moving code from TypeScript 5 to TypeScript 6, developers could validate it with what would become TypeScript 7 language features and get speed and performance boosts while doing so (though nowhere near what TypeScript 7 promised). By completing this first migration of the VS Code codebase, it was possible for developers to be confident that they were ready to shift to the Go-based version when it shipped.
The parallel development of the new language server and extension ensured that by late 2025 it was possible for VS Code development to shift to TypeScript 7, with TypeScript 6 used as a fallback if there were any issues. Those cases could then be reported back to the TypeScript team and used to prioritize development.
As the platform evolved, the use cases for the VS Code team changed. By early 2026 TypeScript 7 was stable and nearly feature-complete, so the team began to use it to build all of their own built-in extensions. This allowed them to rethink their toolchain, changing the bundler from webpack to the one built into esbuild, giving them another speed up. Once that process was tested and working, they could switch all development to TypeScript 7.
Having such a big project take on TypeScript 7 early reaped big rewards, as the resulting virtuous cycle allowed both VS Code and TypeScript to move forward together, fixing issues as they arose and providing valuable feedback. The results speak for themselves. Type checking the entire VS Code codebase is now 7x faster, with most extensions checked in under a second. The only exception was GitHub Copilot, which is almost as big as the editor itself, which type checked in 2.5 seconds.
Compilation has been sped up, dropping from 80 seconds to around 20 seconds. This may not seem a lot, but when you’re compiling and rebuilding and debugging, each change in your code now takes a lot less time. That improves developer productivity and ensures they stay in flow, rather than switching away to check email or Teams each time they start a new build. The same goes for using the language server, where loading the entire project (necessary for error detection and refactoring) now takes 10 seconds rather than a minute.
Lots of little time savings like this add up across a big project and a large team, helping developers stay focused and able to solve problems more effectively. The VS Code blog post notes that it cuts down on coffee runs, which take longer than the load or build that inspire a quick cuppa!
Getting ready for TypeScript 7 in your build pipeline
Microsoft is quick to point out that, while the TypeScript 7.0 release will be production ready, TypeScript 7 won’t have a full programmatic API until the release of TypeScript 7.1. As this won’t be for some time, Microsoft is providing a way to run TypeScript 7 side-by-side with TypeScript 6.
Installing the @typescript/typescript6 compatibility package alongside TypeScript 7 adds a new executable, tsc6, that allows you to modify code that uses the TypeScript 5 API to run using TypeScript 6, by renaming the calls to tsc in your scripts to tsc6. This should allow you to keep building to the latest releases at the same time as starting to experiment with using the new runtime.
It’s not a perfect fix. You do need to do some work to implement npm aliases that allow linters and other low-level tools to work with both versions. You can also provide two different dependencies in your package.json to allow TypeScript 6 (tsc6) and TypeScript 7 (tsc) to run side-by-side. The result is a way to help migrate TypeScript code to the newer platform, delivering more efficient code that runs on a more modern ECMAScript in the meantime.
TypeScript 7 will be a big upgrade, though it has taken surprisingly little time to deliver. With users like the Visual Studio Code team already building on the new release, it’s clear that beginning your own migration should be easier than you might have thought.
The final release is due sometime in July 2026. If you haven’t started looking at TypeScript 7, now is the time to start.