TypeScript 7 Went GA on July 8. Three Weeks In, Here's What the Go Rewrite Actually Costs a Solo Codebase
TypeScript 7.0 hit general availability on July 8, a native Go port of the compiler that Microsoft clocks at 8x to 12x faster on full builds, and it's not an opt-in preview anymore. Run npm install -D typescript today with no version pin and you get 7.0 under the normal latest tag. Back in April I wrote about this as a nightly preview close to GA and told solo devs it would be three commands, one config flag, done. Three weeks of real migration reports now exist that didn't exist then, and they complicate that answer in a way worth updating.
What actually shipped
The RC landed June 18, GA followed on July 8, just under three weeks later, matching what Microsoft said to expect. This is the finished version of the port my April post covered as @typescript/native-preview: over a year of rewriting the compiler, type checker, and language service from TypeScript-on-Node into Go, with the semantics kept deliberately identical to 6.0. Microsoft's own published numbers, across five real open-source codebases at default settings, range from 7.7x on tldraw to 11.9x on VS Code (125.7 seconds down to 10.6). Crank the --checkers flag from its default of 4 to 8 and VS Code gets to 7.51 seconds, 16.7x, though that's a tuned run, not what a fresh install gives you.
The pre-release testing list is the part that makes this credible rather than marketing: Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, and VoidZero all ran TypeScript 7 against their own codebases before GA. Slack says it cut CI type-checking from about 7.5 minutes to 1.25 and killed 40% of its merge-queue time. Canva's time-to-first-error in the editor dropped from roughly 58 seconds to 4.8. Those are vendor-relayed numbers, not independently audited, but they're specific enough and consistent enough across unrelated companies that I believe the direction, if not the exact decimal.
The gap nobody's marketing slide mentioned
Here's what the April post genuinely couldn't have told you, because the decision hadn't been made yet: TypeScript 7.0 shipped without a stable programmatic API. Microsoft says 7.1 will ship a new one, expected around October on the usual three-to-four-month cadence, but until then, anything that embeds TypeScript's compiler rather than just shelling out to tsc is stuck on 6.0.
The clearest evidence of how much that matters showed up on GA day itself: a TypeScript 7 support request filed against typescript-eslint was closed as "not planned," and ESLint's own core repos are now queued behind that decision. Vue, Svelte, MDX, and Astro's template tooling are in the same boat: all of them are Volar-based, all of them need the old API, none of them can run on 7.0 yet. Astro's own tracking discussion for this has been open and explicitly exploratory since March, four months with no committed plan as of GA. That's not a footnote for this blog specifically: this site's own tsconfig.json extends astro/tsconfigs/strict, and any type checking that routes through the Astro language server rather than bare tsc is, right now, running on tooling that hasn't moved yet.
Bare tsc and a bundler like esbuild have no dependency on that API and migrate cleanly. Anything with type-aware lint rules, embedded-language editor support, or a custom transformer sitting on top of the compiler does not.
Updating the April call
The April post's line was "three commands, one config flag, done." With real data in, that holds for the case I actually described: a solo Astro, Next, or Hono project with a standard toolchain and no custom compiler plugins. npm install -D typescript, run tsc --noEmit, reconcile a handful of hard-defaulted flags: strict is now true, types defaults to an empty array instead of everything, rootDir needs to be explicit if your tsconfig.json doesn't sit next to src. None of that requires custom tooling.
It breaks down exactly where the April post flagged it might, but with more teeth than I expected. If you're running ts-patch, a custom transformer, or exotic build-time codegen (common in monorepos, less common but not rare in ambitious solo projects), you're not upgrading tsc in isolation, you're waiting on whatever plugin you depend on to either bridge the gap or port to the 7.1 API once it exists. And if your editor tooling depends on a language-service plugin for your framework, check whether that framework is Volar-based before you assume your editor experience just got faster. It might not have moved at all.
The actual upgrade path today
Run npx tsc --version after your next dependency bump, before you assume nothing changed: you may already be on 7.0 without having decided to be. Then:
- Check whether anything in your stack embeds the compiler: typescript-eslint, a Vue/Svelte/Astro/MDX language server, a custom transformer. If none of that applies, you're in the clear-to-move group.
- Reconcile your
tsconfig.jsonagainst the new hard defaults before you runtsc --noEmitfor real, or you'll spend your first pass debugging config instead of code. - If something in your toolchain does need the old API, Microsoft shipped
@typescript/typescript6, which gives you atsc6binary and re-exports the 6.0 API so that piece keeps working whiletscitself runs on 7.0. That's the split setup most week-one adopters landed on.
Budget an afternoon, not the ten minutes the announcement implies. Most of that afternoon goes to config reconciliation and checking your editor plugins, not to actual code changes.
The honest take
For a solo operator on a standard Vite, Next.js, or Astro setup with no exotic build plugins, this is close to a non-event once you clear the config-default sweep: faster builds, same output, and an editor that stops stalling on large refactors. I said that in April as a prediction; it's now a fact with three weeks of adopter data behind it, and I'd stand by upgrading this week if that's your setup.
The counter-take, and it's a real one: the horror stories concentrate almost entirely in large legacy monorepos with custom compiler tooling, and those aren't hypothetical anymore: typescript-eslint closing the door on day one and Astro's four-month-old exploratory ticket are exactly that pattern playing out in public. If you're a solo dev who happens to lean on type-aware ESLint rules or a framework with Volar-based tooling, you are, for now, in the same blocked bucket as the enterprise monorepos, through no fault of your own. Check tsc --version, check what your editor plugin actually depends on, and don't assume "solo project" automatically means "unaffected." Some of us just found out we're not.
Author
Lukas
@lukcombinator