TypeScript 7.0: the Go compiler and the end of slow builds

The Go native compiler landed on 8 July: full builds 8 to 12 times faster and the first error in the editor after 1.3 seconds instead of 17.5. The benchmarks, the breaking changes, and how to schedule the migration.

Microsoft shipped TypeScript 7.0 on 8 July 2026, three weeks after the 18 June release candidate. It is the native port of the compiler to Go, replacing the JavaScript codebase that ended with TypeScript 6.0 on 23 March 2026. For once the business case for an upgrade is arithmetic rather than opinion: typechecking drops from minutes to seconds. Which does not mean it is free.

The numbers, which this time matter

Microsoft's published benchmarks are full builds of real projects: VS Code from 125.7 to 10.6 seconds (11.9x), Sentry from 139.8 to 15.7 (8.9x), Bluesky from 24.3 to 2.8 (8.7x), Playwright from 12.8 to 1.47 (8.7x), Tldraw from 11.2 to 1.46 (7.7x). Peak memory falls between 6% and 26%: on VS Code from 5.2 to 4.2 GB.

The figure that actually changes your day is not the CI one. In the VS Code codebase, opening a file with an error used to take around 17.5 seconds before the first error appeared; it now takes 1.3. The language server reports over 80% fewer failing commands and over 60% fewer crashes. Near-instant feedback changes how you write code, not just how long you wait.

Why the maths works on a small project too

The standard objection: our monorepo is not VS Code. True, but the gain is multiplicative, not absolute. On the projects we maintain, typechecking is almost always the slowest pipeline step after the tests, and it runs on every push. Dividing that by eight means minutes of waiting and of billed runner time saved every day. It is one of the very few cost lines that falls without touching a line of application code.

Where the upgrade costs you

strict on by default: on a codebase that never had it, the upgrade surfaces real, pre-existing errors, not false positives. How many there are is unknowable until you run the compiler.
types now defaults to []: @types packages are no longer all loaded automatically. Implicit type dependencies have to be declared one by one.
Removed options: the es5 target, AMD, UMD and SystemJS modules, classic module resolution and baseUrl are gone, and the compiler stops with an error rather than warning. The defaults for module (esnext) and rootDir (./) change too.
No compiler API: 7.0 does not expose the public programmatic API, which is expected with 7.1. typescript-eslint, Vue, Svelte, Astro, MDX and Angular template type-checking cannot run on it for now. The @typescript/typescript6 package installs a side-by-side binary to cover the gap.

How we are scheduling it

New projects: TypeScript 7 from the first commit, the new defaults are the right ones. Existing React or Next.js projects: doable now, on a dedicated branch, counting the hours to clear the strict errors before you commit to anything. Vue, Svelte or Astro projects: wait for the new API, full stop.

Verdict

Do it, and put it on the calendar. A factor of eight on typechecking does not come round twice in a project's life, and the editor latency alone pays for the day. But it is a migration, not a version bump: schedule it for Q4, on a branch, with someone assigned to clear the strict errors. Not on a Friday afternoon.