TypeScript 7 Ships Its Go Compiler, and the Missing API Is the Real Migration Story
Microsoft's native port delivers the order-of-magnitude speedups it promised, but every tool that embeds the compiler is left waiting for 7.1.
Microsoft released TypeScript 7.0 on 8 July, the first stable version built on the native port of the compiler and language service to Go. Installing it is undramatic: it is still the typescript package on npm and the binary is still tsc. For teams that are not ready, TypeScript 6 can sit alongside it under an npm alias, @typescript/typescript6, which exposes a tsc6 binary.
The headline is speed, and this time the numbers come from real codebases rather than toy benchmarks. Type-checking the VS Code repository drops from 125.7 seconds to 10.6 seconds, an 11.9x improvement. Sentry goes from 139.8 to 15.7 seconds, Bluesky from 24.3 to 2.8, Playwright from 12.8 to 1.47, and tldraw from 11.2 to 1.46. The new --checkers flag controls how many parallel type-checking workers run (the default is four); at eight, Microsoft reports VS Code checking 16.7x faster than on 6.0.
Speed is the easy part
As a performance engineer I am more interested in what did not move as much. Memory use falls, but modestly: VS Code goes from 5.2GB to 4.2GB, Sentry barely shifts from 4.9GB to 4.6GB. If your CI runners are memory-bound rather than CPU-bound, do not expect the same transformation, and be careful about cranking --checkers up on small machines before you have measured peak usage.
The editor story is arguably more important than the build story. Microsoft says time to surface errors in VS Code fell from 17.5 seconds to under 1.3, and that the language server has 80% fewer failing commands and 60% fewer crashes than 6.0. That is the change most developers will feel every day, long before they notice a shorter CI job.
The breaking changes are deliberate
TypeScript 6.0 was positioned as the bridge release, and 7.0 is where the deprecated options become hard errors. target: es5, downlevelIteration, baseUrl, the node/node10 and classic module resolution modes, and the AMD, UMD and SystemJS module formats are all gone. esModuleInterop can no longer be turned off.
The defaults have also shifted: strict is now on, module defaults to esnext, and types now defaults to an empty array. That last one is the quiet trap. Projects that relied on every installed @types package being picked up automatically will see a wave of missing-global errors and need to list what they actually use. Plain JavaScript projects checked through JSDoc should also read the notes carefully, because several JSDoc patterns, including @enum and @class, are no longer recognised.
No API, no full migration
The detail that will decide most teams' timelines is a single line in the announcement: TypeScript 7.0 does not ship with a programmatic API. Microsoft expects one in 7.1. Until then, anything that drives the compiler from code rather than through the command line stays on the old implementation. The post names typescript-eslint and the template and embedded-language tooling for Vue, MDX, Astro, Svelte and Angular as affected.
In practice that means many front-end projects will run a split toolchain for a while: tsc 7 for type-checking in CI and the editor, and TypeScript 6 underneath linting and framework tooling. That is workable, but it means two compilers that can disagree, and two sets of configuration rules, since 6.x still accepts options that 7.0 now rejects. I would keep a single tsconfig that satisfies 7.0 and let 6.x consume it, rather than maintaining two.
What to watch
- 7.1 and the API. Microsoft is promising feature releases every three to four months. Whether the API lands in the first of those, and how closely it resembles the old one, determines when lint and framework tooling can follow.
- Framework language servers. Vue and Svelte users get the fastest compiler only for
.tsfiles until their tools catch up. Expect uneven editor performance inside the same project. - Unicode edge cases. The release changes how template literal types handle UTF-16 strings. Libraries that do type-level string manipulation should test before their users do.
The port is a genuine engineering achievement, and the build-time savings on large monorepos are real money. But the sensible plan for most teams this month is to adopt 7.0 for checking, fix the configuration errors it surfaces, and leave the rest of the pipeline alone until 7.1 tells us what the API looks like.
Sources