TypeScript 7, One Week In: The real migration readiness check

TypeScript 7 migration looked simple on paper: install the new native compiler, collect an 8-12x build-time win. One week after the July 8, 2026 GA, the real picture is sharper and more useful — the Go-based compiler itself has been stable, while the tooling ecosystem around it is openly broken or blocked in ways Microsoft's launch messaging only partly prepared teams for.

The single most citable fact of week one is not a benchmark. It is a GitHub issue: a TypeScript 7 support request filed against typescript-eslint on GA day and closed as "not planned." ESLint's own repositories are queued behind that decision, and every Volar-style template checker — Vue, Svelte, MDX, Astro — cannot run TS7 at all until a stable programmatic API ships in 7.1, expected around October.

This post is the week-one retrospective: what actually broke, a framework-by-framework readiness scorecard, how much weight to put on the speed claims now that independent reports exist, and a concrete decision matrix for when your team should move. For the GA-day breaking changes and install steps, see our GA-day migration playbook; for the run-up, our coverage from when TypeScript 7 was still an RC.

The context in one paragraph: TypeScript 7.0 reached general availability on July 8, 2026 — a full port of the compiler and language service from TypeScript-on-Node to Go, completing what Microsoft called Project Corsa. The announcement claimed 8x-12x faster full builds at default settings, memory reductions of 6% to 26% across benchmarked projects, and editor error-detection on VS Code's 2.3-million-line codebase dropping from roughly 17.5 seconds to under 1.3. Those launch-day numbers, and the breaking changes that come with them, are covered in depth in the GA-day playbook — this post is about what happened next.

What happened next was a stress test no vendor benchmark can simulate: thousands of teams ran npm install against their existing toolchains. The compiler passed. The toolchain around it, in several load-bearing places, did not. Meanwhile new performance detail kept arriving — TechTimes reported that raising the new --checkers flag from its default of 4 to 8 cuts VS Code's build from 10.6 seconds to 7.51, roughly 16.7x over TS6 — a tuning most teams have not touched in week one.

Here is the week-one failure most teams will actually hit. typescript-eslint's supported TypeScript range is >=4.8.4 <6.1.0 — TypeScript 7 sits entirely outside it. On GA day, a developer filed issue #12518 asking for TypeScript 7.0.2 support. The install fails at the npm peer-dependency check; forcing past it produces a runtime crash when linting — TypeError: Cannot read properties of undefined (reading 'Cjs') — while npm run build succeeds. The maintainers closed the issue as "not planned."

The follow-up tells you where this is heading in the short term. A companion issue, #12521, proposes showing a "user-friendly message if TS 7 is detected." Read that carefully: the maintainers' week-one priority is not compatibility — it is a clearer error when you try. And the gap cascades upward: ESLint's own repositories (eslint/eslint, eslint/rewrite, eslint/js) are explicitly blocked on typescript-eslint adding TS7 support, per eslint/eslint#21070. A lint stack most of the TypeScript world depends on is, for now, structurally incompatible with the new compiler.

Existing coverage treats framework readiness as a paragraph of caveats. Pulled into one table with statuses as of July 16, 2026, the shape of the problem is much clearer: everything that shells out to tsc works today, and everything that embeds TypeScript's programmatic API is stuck in a queue behind 7.1.

Two readings of this table matter. First, the "Ready" tier is bigger than the discourse suggests — a plain tsc-plus-bundler stack, which describes a large share of Next.js and React codebases, migrates cleanly today. Second, the "Blocked" tier has no committed dates outside Microsoft's own 7.1 statement. typescript-eslint has published no timeline, and Astro's tracking discussion has been open and explicitly exploratory since March 16 — four months, still no committed plan. That is the quiet tension of week one: Microsoft frames the API gap as point-in-time, but the concrete evidence suggests the gap is wider in practice than the GA messaging implied.

A week in, the performance picture has three tiers of evidence that most coverage blurs together: Microsoft's own benchmark suite, adopter quotes Microsoft selected for the announcement, and the first genuinely independent community reports. They point the same direction — but they carry very different weight, and the distinction matters if you're building a migration case for your own team.

The honest synthesis: the independent evidence is directionally consistent with Microsoft's range and far thinner than the headlines imply. One unnamed community project reporting 45-60 second builds dropping to 4-8 seconds is real signal — it is also a single report, relayed through secondary press. And there is a structural blind spot in every number published so far: nobody has measured TS7 on a monorepo with heavy typescript-eslint or Volar dependencies, because those setups cannot run it at all. The codebases most likely to have complex, slow builds are precisely the ones still locked out. Microsoft's own claim that the Go port passed the existing test suite with only 74 behavioral differences across tens of thousands of cases is reassuring on correctness — but it, too, is vendor-stated.

One more calibration point: the pre-GA nightly builds under @typescript/native-preview reportedly accumulated weekly downloads in the millions before GA — evidence of substantial pre-release testing volume, though the widely circulated figure comes from press synthesis rather than a directly verifiable npm stat, so treat the magnitude as directional.

Everything in the blocked tier traces to one decision: TypeScript 7.0 shipped without a stable programmatic API, and Microsoft has said 7.1 will ship "a new (and different) API" rather than carrying the old JS-based surface forward. Astro's community tracking discussion puts it plainly: "the programmatic Language Service API is still in progress...the TypeScript team has indicated that the existing JS-based API surface will not be carried forward into TS 7." On the historical 3-4 month release cadence, 7.1 lands around October 2026 — and every tool that embeds the compiler, from lint rules to template checkers to custom analyzers (including the kind you'd write when building an MCP server in TypeScript), will then have a porting project of its own.

In the meantime, three operating modes have emerged among teams that tried to move in week one:

The Hacker News launch thread — 719 points and 301 comments by the one-week mark — is the best single read on developer sentiment, and it was broadly positive on speed. Notably, the most-upvoted top comment did not celebrate; it reproduced Microsoft's benchmark table and asked how downstream build tools like tsdown and esbuild would be affected. TypeScript lead Daniel Rosenwasser answered inline: "esbuild doesn't rely on TypeScript at all, so there's no issue there" — and tsdown needs the TS6 side-by-side package only when using --isolatedDeclarations. The community's center of gravity, in other words, matched this post's framing: the question was never the compiler, it was the toolchain.

Two more threads from the discussion are worth recording. First, commenters surfaced that Copilot and AI assistance were used extensively in the typescript-go port, citing specific pull requests — with one commenter asserting, from their own reading of the git history, that "Copilot is the user with the 2nd most commits." That is a community claim, not something verified against the repository's commit log, but it is a striking data point about how a flagship compiler port was staffed in 2026. Second, the port has a cultural cost the speed numbers hide: after 14 years of a self-hosted compiler — TypeScript written in TypeScript, able to compile itself — contributing to the compiler now requires Go. The performance was purchased with a change in who can easily work on the language.

Projected forward, week one reads like the start of a familiar curve rather than a stumble. The compiler is done; the ecosystem has an October-shaped deadline and no choice but to port, because the performance delta is too large for tool maintainers to ignore once a stable API exists. The typescript-eslint "not planned" close is best read not as refusal but as sequencing — waiting for the API that will actually be carried forward. The practical risk to watch is not whether the ecosystem ports, but whether 7.1 slips: every blocked row in the scorecard above compounds on that single date.

The migration call is now a function of your toolchain, not your appetite for new compilers. Find your row.

If you're in that last group, start with the intermediate hop: our guide to TypeScript 5.9's feature set covers the last of the 5.x line, and if you're still clearing a TypeScript 5 floor for supabase-js, that checklist is the same muscle you'll need for 6.0's deprecation sweep. And if your team wants the migration handled — toolchain audit, split-setup wiring, the 6.0 deprecation sweep, and the 7.1 re-check when it ships — that's exactly the kind of engagement our web development team runs.