Iterating faster with TypeScript 7

📼 Rewatch VS Code Live at MS Build 2026

Dismiss this update

Iterating faster with TypeScript 7

June 26, 2026 by VS Code Team, @code

VS Code and TypeScript practically grew up together. We made a bet early on to write VS Code in TypeScript, and we have always worked closely with the TypeScript team to provide great built-in TypeScript and JavaScript language support in VS Code. This post is about the next step of that journey: TypeScript 7, and how collaborating on adopting TypeScript 7 sped up our builds, improved the day-to-day editing loop for both developers and agents, and helped the TypeScript team ship a more tested release.

TypeScript 7 is a complete port of the TypeScript compiler and language tooling in Go. That means it's fast, more than 10x faster in many cases. VS Code had a lot to gain from those speedups, so we were naturally eager to adopt TypeScript 7 as soon as we could.

However, we also knew that this would take time. When we started this process in the summer of 2025, TypeScript 7 was actually already shockingly far along for a complete rewrite, but it still had type checking inconsistencies and lacked many features we needed. Even so, we wanted to start testing and providing feedback right away. Adopting TypeScript 7 while it was still being built may sound a little crazy, but it turned out to be a great decision for both VS Code and TypeScript.

An incremental migration

The VS Code team has never been afraid to take on large engineering efforts, whether that's enabling strict null checking in our codebase, adding remote development support, or addressing and preventing dangerous code patterns across thousands of files. A common theme across these efforts is that we try to take an incremental approach. This means breaking big, complex problems down into small steps. Those steps happen in the main codebase (no forks or long-lived branches), and each one usually brings a small improvement as it lands. Take enough little steps, and eventually you can look back and realize that you've quietly conquered that once seemingly insurmountable challenge.

We wanted to take the same approach to adopting TypeScript 7. For us, that meant gradually introducing TypeScript 7 into different parts of our workflows and codebases, starting with lower-impact, lower-risk areas before eventually moving on to the main areas of VS Code. There are many benefits to working incrementally, but two were especially important for this effort:

Reduced risk. Each step of the adoption was relatively small, so if something went wrong, it was easy to identify the cause and revert.

Early feedback. We wanted to start testing and providing high-quality feedback to the TS team early in TS 7's development. That meant getting as much usage of TypeScript 7 as possible, but without negatively impacting developer productivity on the VS Code team.

This testing helped us find bugs and limitations that they could then prioritize fixing. And as we adopted TS 7 in more parts of our codebase, those areas also became informal regression tests for each new TypeScript 7 nightly release.

In practice, that incremental philosophy unfolded as a series of phases over about six months. Each phase increased our use and testing of TypeScript 7 a little more, moving in step with TypeScript 7's own progress and helping shape it along the way. Here's how it played out:

Exploration (summer and early fall 2025)

TypeScript 7 was publicly announced in March 2025. By the summer, it was ready for initial testing, although at this point it still had known bugs and limitations.

Type checking was farther along than emit (the process of generating JavaScript output files), so most of our early testing focused on manually running the @typescript/native-preview npm package on some of our smaller extensions with --noEmit. We reported issues as we found them, and because the native-preview package was updated daily, we could test new changes and fixes quickly.

As part of TypeScript 7, the TypeScript team was also building up the new language server that would power VS Code's in-editor TypeScript and JavaScript support. This was shipped using the TypeScript native preview VS Code extension, which replaces VS Code's built-in JavaScript and TypeScript IntelliSense with the new TypeScript 7 language server. We worked with the TypeScript team to make it easy to switch back and forth between the two TypeScript versions. That flexibility mattered because TypeScript 7 was still missing a number of basic language features at this point. We wanted developers to feel that they could try it out with as little effort and risk as possible.

We also made it easy to report TypeScript 7 issues directly from VS Code. Making reporting easy meant that developers would not think twice about filing even small annoyances. Those reports fed a steady stream of real world feedback for the TypeScript team.

At this stage, most testing was...