Quick take: TypeScript 7 works today on React, Next.js, Node, and plain TypeScript. It does not fully work yet on Vue, Svelte, Astro, MDX, or Angular template checking, because those tools need a stable programmatic compiler API the native build hasn't shipped. Stay on TypeScript 6 for type-checking those stacks.
So you upgraded to the shiny native compiler and your Astro project's astro check fell over? You're not doing anything wrong. Whether a framework can use TypeScript 7 comes down to one question: does it call tsc on the command line, or does it reach into the compiler as a library? React, Next.js, Node, and plain TypeScript only ask tsc to type-check and emit, so they run on the Go compiler today. Vue, Svelte, Astro, MDX, and Angular's template checker do something deeper. They import the TypeScript API in-process to understand .vue, .svelte, and .astro files, and that API isn't stable in the native build yet. For the wider release story, see the Project Corsa overview.
Why does framework support lag behind the compiler?
The command-line tsc is only part of what TypeScript ships. There's also a programmatic API, the typescript package you can import, plus a language-service plugin API that editors and framework tools bind against. Tools like vue-tsc, svelte-check, and astro check don't shell out to tsc. They embed the compiler and feed it virtual files. A .vue single-file component gets split into a script block, a template, and a synthesized render function, all built in memory before the checker ever sees them. That trick needs deep, stable access to the compiler's internals.
TypeScript 7 rewrote those internals in Go. The command-line surface matches TypeScript 6 closely, so tsc and the editor language server both work. But the full programmatic API, the one third-party tools depend on, hasn't been finalized for the native compiler. Microsoft has been clear the API is coming, just not at 7.0. Until it lands, vue-tsc and friends literally can't drive the native checker, because the functions they call either aren't exposed yet or don't match the old signatures.
Is this a bug? No. It's sequencing. Shipping the compiler first and the embedding API second is a reasonable order, and honestly it was the right call, even if it stings when your framework sits on the wrong side of the line.
The TypeScript 7 framework support matrix
Here's where each major toolchain sits at GA, and what I'd actually do today.
| Framework or tool | Status at GA | What to do now |
|---|---|---|
| React, Next.js | Works | Upgrade; tsc and the editor server are both native |
| Node, plain TypeScript | Works | Upgrade; run tsc 7 directly for build and check |
Vue (vue-tsc) | Not ready | Keep TypeScript 6 for type-checking |
Svelte (svelte-check) | Not ready | Keep TypeScript 6 for type-checking |
Astro (astro check) | Not ready | Keep TypeScript 6 for type-checking |
| MDX type-checking | Not ready | Keep TypeScript 6 |
| Angular templates | Partial | Stick with Angular's bundled compiler |
The React row deserves a footnote. Plain React and Next.js work, but your Vite plugin and ESLint parser want to be on matching versions, so bump the whole toolchain together rather than one package at a time.
What about Astro, which so many of you use?
Astro earns its own callout, because a lot of you build content sites with it, this blog's siblings included. When I flipped an Astro repo to the native preview last week, astro check simply refused to type-check the .astro frontmatter and components. The CLI build still ran, because Vite does the bundling and type errors don't block a build by default, but I'd lost real type-checking. So I pin TypeScript 6 in every Astro repo for now and leave the editor extension on the classic experience there. There's nothing more to configure. It just keeps working.
How do you keep shipping on Vue, Svelte, or Astro today?
You've got two clean paths, and they coexist in one repo.
First, keep TypeScript 6 as the type-checker for anything framework-specific. TypeScript 6 was the final JavaScript-based release and it's the supported bridge, so vue-tsc and svelte-check run against it exactly as before:
# Framework package: stay on the last JS-based release for type-checking
npm install -D typescript@6
npx vue-tsc --noEmit # or svelte-check, or astro checkSecond, use the native tsc 7 for build-only steps where no framework plugin is involved. Got a shared types package, a Node script folder, or a plain-TS utility library in the same workspace? Those don't parse .vue or .astro files, so give each one its own TypeScript 7 pin and take the speedup:
// package.json inside a plain-TypeScript package
{
"scripts": {
"typecheck": "tsc --noEmit"
},
"devDependencies": {
"typescript": "^7.0.0"
}
}In a Yarn or npm workspace, each package resolves its own typescript, so the Vue app stays on 6 while the shared library checks on 7. If part of your stack is a set of Node scripts, that side is unaffected by the gap anyway, since Node runs TypeScript natively without touching framework tooling at all.
When will the gap close?
Soon, and that's not hand-waving. The programmatic API is the last big piece of the native rollout, and the Vue, Svelte, and Astro maintainers have coordinated with the TypeScript team through the whole preview. Expect vue-tsc, svelte-check, and astro check to ship native-compatible builds within a release cycle or two of the API stabilizing, not years out. My honest read? Don't rewrite your build to force TypeScript 7 onto a Vue or Astro app right now. The payoff is a faster type-check you'll get for free the moment the tooling catches up, so waiting a few months beats fighting an API that isn't done.
Until then, split the difference. Native tsc 7 for the plain-TypeScript and React parts of your stack, TypeScript 6 for the framework type-check. One repo, two compilers, zero drama.
Related
- step-by-step migration guide - the exact upgrade path to run once your framework's tooling supports the native compiler
- Framework changelogs - watch the
vue-tsc,svelte-check, andastro checkreleases for the first native-compatible version, then flip your pin