A compiler ten times faster, an ecosystem one version behind

The TypeScript compiler has been rewritten in Go and the stable release landed on 8 July 2026. The headline claim is a tenfold speedup; the announcement itself is more careful and gives a range of 8x to 12x on full builds. But the subject of this piece is not the speed, it is what did not arrive alongside it. TypeScript 7.0 ships without a programmatic API, and that missing piece is exactly where a project’s gates rest.

The numbers are real, and where they were taken matters

The table in the announcement was measured on five real repositories and puts TypeScript 6 and TypeScript 7 side by side.

• vscode: 125.7 seconds down to 10.6, a factor of 11.9.
• sentry: 139.8 seconds down to 15.7, a factor of 8.9.
• bluesky: 24.3 seconds down to 2.8, a factor of 8.7.
• playwright: 12.8 seconds down to 1.47, a factor of 8.7.
• tldraw: 11.2 seconds down to 1.46, a factor of 7.7.

Those are full build numbers, which is what continuous integration measures. There is a second number that means more day to day: opening a file carrying an error used to take about 17.5 seconds in the editor, and takes under 1.3 seconds with TypeScript 7. An independent news summary also reports memory use down by roughly 18 per cent and one team’s continuous integration step falling from 7.5 minutes to 1.25.

What is missing is an API, and it is clear who pays for it

While TypeScript 7.0 is here, it does not ship with an API. We expect TypeScript 7.1 to ship with a new (and different) API, but until then we have made it a priority to ensure TypeScript can be run side-by-side with TypeScript 6.0 for utilities that still need some programmatic access to the compiler (such as typescript-eslint).

That sentence is from the announcement itself. In practice it means every tool that calls the compiler programmatically cannot run on TypeScript 7. The two tools the announcement names are typescript-eslint and Volar, plus template type checking for Vue, Svelte, Astro, MDX and Angular, because those embed the compiler too. It does not name them, but every tool built on the compiler API sits in the same class, ts-jest and ts-morph among them. The release candidate announcement said it even more plainly: a stable programmatic API is at best several months away.

You can see the concrete shape of it in one support thread. On the day of the announcement, a developer filed an issue about upgrading a Vite plus React project: npm ci fails because a peer range caps TypeScript below 6.1.0, and forcing the install makes ESLint crash while running. The issue was closed as not planned. That is not a bug report, it is a boundary marker.

Where the cost of a rewrite collects

The part of this that will still read well in a year is that the cost of rewriting a compiler collects not in the compiler but in the surface attached to it. The repository where the port was carried out says so openly: parsing, type resolution, type checking, JSX, declaration emit, watch mode, project references and incremental build are all marked done. Two things are not. The language service is in progress and the API is not ready.

So the hard part was never the algorithms, it was reproducing an interface that took a decade to accumulate in a new language. That is also the honest definition of a rewrite: one binary that does the same job faster, plus a queue the rest of the ecosystem is standing in.

Not an upgrade, a migration

The second cost is in configuration. TypeScript 7 now treats a set of options as hard errors: target: es5, downlevelIteration, node10 and classic for moduleResolution, amd, umd, systemjs and none for module, and baseUrl. esModuleInterop and allowSyntheticDefaultImports can no longer be false. The release candidate announcement lists two default changes as well: rootDir now defaults to ./ rather than being inferred, and types defaults to [] rather than ["*"], so type packages have to be named one by one.

The good thing about that list is that you do not need to upgrade to see any of it. Opening tsconfig.json today and searching for those keys finishes the measurable half of the migration without touching a version. There is also a compatibility package for the transition, @typescript/typescript6, which hands back the old API and a tsc6 binary so the two versions can run side by side. So today’s answer is not wait, it is install both.

Two major versions in one quarter

The timetable is a decision in its own right. TypeScript 6.0 shipped on 23 March 2026 and 7.0 on 8 July of the same year, two major versions three and a half months apart. The explanation is not haste but a migration split in two: the 6.0 announcement describes itself as the bridge between 5.9 and 7.0 and says most of its changes exist to prepare for adopting 7.0.

The useful part of that split is this: most of the options that are hard errors in 7.0 were already marked deprecated in 6.0, target: es5 and moduleResolution: node10 among them. So for a project that went to 6.0 and cleared its warnings, 7.0 is only a change of compiler; for a project that did not, it is the configuration migration and the compiler change at once. That is what the version number is saying: not a compatibility promise but a marker of which stage of the migration you are in.

In practice that means planning the upgrade as two steps rather than one jump. The first step carries no ecosystem risk, because 6.0 still ships the old programmatic API and runs alongside typescript-eslint. The timetable for the second step is not yours, it belongs to your tools, and today that timetable is waiting on 7.1.

What would change in this repository

This site is easy to measure because its gate is written down: one script, eight steps, nine with the cms integration suite added, and one run finishes in under two minutes on this machine. Two of those nine steps are tsc --noEmit and one is lint. So TypeScript 7 would make two steps faster here and put one in the dark, because the lint configuration in both apps rests on typescript-eslint. In a repository this size the compiler is not the bottleneck anyway: the gain is in the editor rather than in continuous integration, while the loss is a gate outright.

The decision follows from that, and it is not general advice. If nothing but a gate that runs the compiler directly depends on it, upgrading is cheap today. If your gates include a lint rule that uses type information, a template checker or a code transformer, upgrading today means closing a gate. The difference between the two is not a preference, it is an inventory question.

It comes down to three moves. First, clean the removed options out of tsconfig.json today: independent of the upgrade, reversible and cheap. Second, write down which of your gates calls the compiler programmatically; that list is usually short, and it is what actually sets the timetable. Third, measure the speed gain in the right place: tenfold is a number taken on a full build, and what most teams feel day to day is not a full build but how fast the editor answers.