Frontend / TypeScript
TypeScript 7 in Go: speed and migration risks
TypeScript 7 moves the compiler and language service from JavaScript to Go. Syntax does not become faster; the feedback loop that modern development depends on does.
Why rewrite the foundation
Large TypeScript projects spend significant time loading, type-checking, and serving editor operations. A native implementation can use shared-memory parallelism and scale better across cores.
This matters in agent workflows: faster compiler feedback means more “change, check, repair” cycles in the same amount of time.
TypeScript 6 as the bridge
TypeScript 6 is the final release of the JavaScript codebase and prepares defaults for the new era: strict mode, ESM-oriented modules, a modern ECMAScript target, and more explicit global types.
Upgrade to 6.x first and remove deprecated options. That turns one large jump into two controlled migrations.
The main 7.0 limitation
The first TypeScript 7 release does not expose a stable programmatic API. Tools embedding the compiler or language service cannot migrate immediately, affecting Vue, MDX, Astro, Svelte, Angular, and custom transforms.
The transitional @typescript/typescript6 package can keep the version 6 API beside the fast compiler, but that split must be documented and pinned.
How to decide
Try TypeScript 7 first as an additional CI check. Compare diagnostics, speed, and compatibility before changing every editor.
A plain React and Vite project may migrate quickly. A monorepo with custom transformers and embedded languages should probably wait for the 7.1 API.