chore(deps): update dependency typescript to v7

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
typescript (source)	~6.0.0 → ~7.0.0
typescript (source)	^5.9.3 → ^7.0.0

---

Release Notes

microsoft/TypeScript (typescript)

v7.0.2

Compare Source

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • "before 9am on Monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[dawsontoth]

Reviewed via scheduled Renovate triage. Diff bumps typescript ~6 → ~7 in the template scaffolds. Format, Lint, and all npm + yarn generate jobs pass; the only failures are the Generate * with pnpm jobs, which die in the pnpm self-installer (pnpm: Cannot use 'in' operator to search for 'integrity' in undefined → self-installer exits with code 1). That's unrelated CI/infra breakage in the pnpm bootstrap step, not caused by the TypeScript bump. The TS7 change itself looks fine. Re-running once the pnpm installer is healthy should green this; not requesting changes. 🤖

[dawsontoth]

Holding as draft — TS7 (native compiler) not fully adoptable yet

Took this over and dug into what a TS7 upgrade actually involves. TypeScript 7.0 is the native (Go) compiler port, not a routine minor bump. Parking this in draft and tracking the blockers below.

CI status is misleading here

• The only red checks (Generate * with pnpm) fail in the setup-pnpm action's self-installer while switching pnpm 11.7.0 → 11.12.0 (Cannot use 'in' operator to search for 'integrity' in undefined), before any template is generated. Unrelated infra; a rerun once the installer is healthy would go green.
• But green CI does not validate TS7. No template runs tsc/vue-tsc: build is vite build (esbuild/rolldown), test is node --test (native type-stripping), lint is eslint with @eslint/js (not type-aware). CI only proves the version installs.

Blockers to check on later

• vue-tsc is incompatible with TS7 (the real blocker). TS7's package exports only expose ./lib/version.cjs + a new ./unstable/* API; the classic typescript/lib/tsc entrypoint that vue-tsc (via Volar's runTsc) requires is gone. vue-tsc crashes at load with ERR_PACKAGE_PATH_NOT_EXPORTED, even the latest vue-tsc@3.3.7. Blocks vue-ts + vue-ts-ssr. → Watch @vue/language-tools / vue-tsc for native-TS7 support, then revisit.
• baseUrl removed in TS7 (TS5102) — affects all four TS tsconfigs. Being fixed independently in fix(templates): drop removed baseUrl option from TS tsconfigs #115 (it's also broken under the current TS6 via TS5101).
• Add a real typecheck step (e.g. tsc --noEmit / vue-tsc --noEmit) so this class of breakage is actually caught by CI next time.

What already works

• react-ts + react-ts-ssr typecheck and build cleanly under TS7 after the fix(templates): drop removed baseUrl option from TS tsconfigs #115 baseUrl fix (verified: tsc --noEmit exit 0, @/ imports resolve, vite build succeeds). A React-only adoption is viable later if we decide to split versions; Vue stays on TS6 until vue-tsc catches up.

Leaving in draft so Renovate stops nagging while we track upstream vue-tsc progress.

[dawsontoth]

Reviewed via scheduled Renovate triage. Bumps typescript ~6.0.0 → ~7.0.0 in the scaffold template manifests (template-react-ts, template-vue-ts, and their -ssr variants).

Verified locally by cloning the branch and running the generator suite under Node 24: 213/213 tests pass (37 files).

The only failing CI checks are the Generate * with pnpm jobs, which fail inside the setup-pnpm self-installer (self-installer exits with code 1) — that's the known pnpm-bootstrap CI/infra flakiness, not caused by this bump. The equivalent Generate * with npm and Generate * with yarn jobs, plus the full Test matrix (ubuntu/windows × Node 20/22/24), Lint, Format, and commitlint all pass. Safe to merge once the pnpm jobs are re-run (or the branch is rebased).

[dawsontoth]

Tracking update (2026-07-28) — still blocked, and there's a new blocker

Re-checked all three items from my 07-13 note against the rebased head (ee47c0b) and current upstream. Staying in draft.

🆕 New blocker: typescript-eslint doesn't support TS 7 — this is what's red now

The failure signature changed. It's no longer the pnpm flake — it's 6 real failures: Generate nextjs and Generate nextjs-ts across all three package managers.

typescript-eslint does not support TS 7.0.
Error: typescript-eslint does not support TS 7.0.
    at .../eslint-config-next/node_modules/typescript-eslint/dist/index.js:52:11
ESLint: 9.39.5 — exit code 2

eslint-config-next@16.2.12 depends on typescript-eslint ^8.46.0, so both Next templates get it transitively and eslint . dies at config load. Latest typescript-eslint@8.65.0 still peer-caps at typescript ">=4.8.4 <6.1.0" — a direct install with TS 7.0.2 ERESOLVEs. Upstream tracking: typescript-eslint#10940 (they're targeting TS >=7.1).

This corrects something I got wrong on 07-13 — I wrote that lint isn't type-aware. True for the Vite templates (@eslint/js), not for the Next ones, which pull the full typescript-eslint stack via eslint-config-next.

Also worth flagging: the Next templates are jumping ^5.9.3 → ^7.0.0, skipping 6 entirely, while react/vue go ~6.0.0 → ~7.0.0. Two majors in one hop for the templates that are already the most broken.

Blocker status

• vue-tsc incompatible with TS7 — still open. Retested today with the newest vue-tsc@3.3.8 (published 07-22) against typescript@7.0.2: still crashes at load, ERR_PACKAGE_PATH_NOT_EXPORTED in resolveTscPath (vue-tsc/index.js:73). TS7's exports still don't expose the classic typescript/lib/tsc entrypoint Volar's runTsc needs. Blocks vue-ts + vue-ts-ssr.
• baseUrl removed in TS7 — done. fix(templates): drop removed baseUrl option from TS tsconfigs #115 merged 07-13; confirmed no baseUrl remains in any template tsconfig on this branch.
• typescript-eslint / eslint-config-next incompatible with TS7 — new, blocks nextjs + nextjs-ts.
• Add a real typecheck step (tsc --noEmit / vue-tsc --noEmit) — still worth doing regardless of this PR.

✅ Resolved since last time

The Generate * with pnpm self-installer breakage (Cannot use 'in' operator to search for 'integrity' in undefined) is fixed — pnpm jobs are green for all templates now except the Next ones, and those fail on the lint error above, not the installer.

Where that leaves adoption

react-ts + react-ts-ssr remain the only templates clean under TS7 (verified 07-13 post-#115). Both Vue and Next are now blocked on separate upstream projects — @vue/language-tools and typescript-eslint — neither of which has shipped support. A React-only split is still the viable partial path if we want to move sooner.

Leaving in draft. 🤖

[dawsontoth]

Converting my review state to request changes for bookkeeping. No new analysis — my 07-28 tracking note still stands in full; this just stops the PR from carrying a stale APPROVED from 2026-07-14 (commit d79845ca) that contradicts it.

The approval predates the TS7 investigation. The PR is a draft so it could not have merged, but the review state should not read green while the build is red.

Re-confirmed today against head ee47c0b9 — still blocked, unchanged

The 6 red Generate nextjs* jobs are the same real failure, not the old pnpm flake:

typescript-eslint does not support TS 7.0.
  at node_modules/eslint-config-next/node_modules/typescript-eslint/dist/index.js:52:11

Upstream has not moved. As of today, typescript-eslint@8.65.0 — and every published 8.65.1-alpha.* prerelease — still declares:

"typescript": ">=4.8.4 <6.1.0"

Same cap on @typescript-eslint/typescript-estree@8.65.0. TS 7 remains outside the supported range, tracked upstream at typescript-eslint#10940.

Since the blocker is transitive through eslint-config-next, it is not something this repo can pin around without either dropping the Next.js lint config from the affected templates or holding the scaffolds on TS 6. Keeping this in draft until upstream ships TS >=7.1 support is still the right call — re-request review on me when that lands.

[dawsontoth]

Tracking update (2026-08-14) — still blocked; both upstreams retested on newer releases

Re-verified against the rebased head 389eec8c. Position unchanged — my 07-28 note still stands in full. Recording the retests so nobody repeats them.

typescript-eslint — still no TS 7

Latest stable is now 8.67.0 (published 08-10; it was 8.65.0 when I last checked). The peer range is unchanged:

"typescript": ">=4.8.4 <6.1.0"

Still doesn't admit TS 6, let alone 7. eslint-config-next@16.3.1 still depends on typescript-eslint ^8.46.0, so both Next templates resolve into it transitively.

Reproduced locally from template-nextjs (npm install && npm run lint) — byte-identical to CI:

ESLint: 9.39.5
Error: typescript-eslint does not support TS 7.0.
    at .../eslint-config-next/node_modules/typescript-eslint/dist/index.js:52:11

There is active 8.67.1-alpha.* churn (alphas through 08-13), but nothing stable and nothing that moves the peer cap.

vue-tsc — still no TS 7

Retested vue-tsc@3.3.9 (published 07-31, up from the 3.3.8 I tested on 07-28) against typescript@7.0.2. Crashes identically at load:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tsc' is not defined by "exports"
  in .../typescript/package.json
    at resolveTscPath (.../vue-tsc/index.js:73:43)

One caution on reading CI here

Generate vue-ts and Generate vue-ts-ssr are green, and that is not evidence vue-tsc works. The Vue templates' build is vite build, and no script in those templates invokes vue-tsc at all — it's a devDependency nothing runs. So those jobs cannot fail on a vue-tsc regression, and their green is silent about the blocker above. That's the same gap as my still-open "add a real typecheck step (tsc --noEmit / vue-tsc --noEmit)" item.

The 6 red jobs remain exactly nextjs and nextjs-ts × {npm, yarn, pnpm}, all on the typescript-eslint throw.

Blocker status — no change

• typescript-eslint / eslint-config-next incompatible with TS7 — blocks nextjs + nextjs-ts
• vue-tsc incompatible with TS7 — blocks vue-ts + vue-ts-ssr (invisible to CI, see above)
• Add a real typecheck step
• baseUrl removed in TS7 — done in fix(templates): drop removed baseUrl option from TS tsconfigs #115

react-ts and react-ts-ssr remain the only templates clean under TS7. A React-only split is still the viable partial path if we want to move before both upstreams land support. 🤖

[dawsontoth]

Tracking update (2026-08-19) — still blocked; vue-tsc retested on a release that didn't exist last time

Re-verified against head 389eec8c (unchanged since 08-12 — no rebase since my 08-14 note). Position unchanged, request for changes stands. The diff is still exactly the six template typescript bumps and nothing else.

Recording this one because vue-tsc shipped a release after my last check, so the retest was not a repeat.

vue-tsc 3.3.10 — new release, same crash

vue-tsc@3.3.10 published 08-15, one day after I last tested 3.3.9. Retested it in a clean template-vue-ts scaffold on Node 24.19.0, resolving typescript@7.0.2 / vue-tsc@3.3.10:

$ npx vue-tsc --noEmit
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tsc' is not defined by "exports"
  in .../node_modules/typescript/package.json
    at resolveTscPath (.../node_modules/vue-tsc/index.js:73:43)

Byte-identical to 3.3.9 and 3.3.8. Worth noting 3.3.10's peer is typescript: ">=5.0.0" — open-ended, so npm installs it against TS 7 without complaint and the failure only shows up at runtime. The peer range is not a signal here; only the run is. Still blocks vue-ts + vue-ts-ssr, and still invisible to CI for the reason in my 08-14 note (no template script invokes vue-tsc).

typescript-eslint — no movement at all

Latest stable is still 8.67.0 (unchanged since 08-10), peer cap still:

"typescript": ">=4.8.4 <6.1.0"

I also checked the canary this time, since the alpha churn has been continuous (8.67.1-alpha.21, published today): the canary carries the identical peer cap. So the alpha stream is not quietly approaching TS 7 support — nothing to watch there but the tracking issue, typescript-eslint#10940, which targets TS >=7.1. TS 7.1.0-dev exists on the next tag but there is no stable 7.1, so that milestone can't even be attempted yet.

eslint-config-next@16.3.1 still depends on typescript-eslint ^8.46.0. Reproduced from a clean template-nextjs-ts scaffold:

$ npm run lint
typescript-eslint does not support TS 7.0.
ESLint: 9.39.5
    at .../eslint-config-next/node_modules/typescript-eslint/dist/index.js:52:11

The 6 red jobs remain exactly nextjs and nextjs-ts × {npm, yarn, pnpm}.

Blocker status — no change

• typescript-eslint / eslint-config-next incompatible with TS7 — blocks nextjs + nextjs-ts
• vue-tsc incompatible with TS7 — blocks vue-ts + vue-ts-ssr (invisible to CI)
• Add a real typecheck step (tsc --noEmit / vue-tsc --noEmit)
• baseUrl removed in TS7 — done in fix(templates): drop removed baseUrl option from TS tsconfigs #115

react-ts and react-ts-ssr remain the only templates clean under TS7. A React-only split is still the viable partial path if we want to move before both upstreams land support. Leaving in draft. 🤖

[dawsontoth]

Tracking update (2026-08-25) — vue-tsc@3.3.11 retested, same crash

Head is still 389eec8c, unchanged since 08-12. Position and request for changes stand. Keeping this short since only one input moved.

vue-tsc@3.3.11 published 08-21, after I tested 3.3.10 on 08-19, so this was a real retest rather than a repeat. Clean scaffold, Node 24.19.0, resolving typescript@7.0.2 / vue-tsc@3.3.11:

$ npx vue-tsc --noEmit
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tsc' is not defined by "exports"
  in .../node_modules/typescript/package.json
    at resolveTscPath (.../node_modules/vue-tsc/index.js:73:43)
    at main (.../node_modules/vue-tsc/index.js:44:45)

Byte-identical to 3.3.10, 3.3.9 and 3.3.8. vue-tsc still resolves the compiler by require.resolve('typescript/lib/tsc'), and TS 7 still does not expose that subpath in its exports map — so this is the same unfixed upstream break, not a new one.

The peer range is still open-ended (typescript: ">=5.0.0"), so npm installs the combination without a warning and it only fails when someone actually runs the type check. That matters here because the vue templates on this branch pair vue-tsc: ^3.2.5 — which resolves to 3.3.11 today — with the typescript: ~7.0.0 this PR introduces. Anyone scaffolding vue-ts or vue-ts-ssr off a merged version of this gets a template whose type-check command crashes on the first run.

For completeness on the other side of the diff: typescript latest is still 7.0.2 (everything published since is 7.1.0-dev.* prereleases, which ~7.0.0 won't take), so nothing has moved there either.

No action needed from anyone — recording the retest so the next person doesn't have to wonder whether a newer vue-tsc quietly fixed it. Still blocked on upstream.

[dawsontoth]

Tracking update (2026-08-26) — the blocker is now explicit upstream: this needs TypeScript 7.1, not a typescript-eslint patch

Head is still 389eec8c. Request for changes stands — but the picture changed materially since yesterday's note, so this isn't a repeat. typescript-eslint shipped 8.68.0 stable, and it now fails with a real diagnostic instead of a peer-range mismatch.

Scaffolded template-nextjs-ts clean, npm install (exit 0, peer warnings only), resolving typescript@7.0.2:

$ npm run lint
typescript-eslint does not support TS 7.0.
Please see .../announcing-typescript-7-0/#running-side-by-side-with-typescript-6.0 to run
typescript-eslint using the TS 6 API.
See also https://github.com/typescript-eslint/typescript-eslint/issues/10940 for tracking
typescript-eslint's support for TS >=7.1

Error: typescript-eslint does not support TS 7.0.
    at node_modules/eslint-config-next/node_modules/typescript-eslint/dist/index.js:52:11

That's a deliberate hard guard, and the wording matters: TS >=7.1.

Why waiting on typescript-eslint won't clear this

From issue #10940 (open, labelled blocked by external API), maintainer bradzacher on 2026-07-09:

For now - there is nothing we can do to support tsgo / TSv7 ... there is currently no stable JS API.

TypeScript 7.0 ships without a JS API at all; 7.1 is expected to introduce a new one. The thread is locked to cut noise. So no typescript-eslint release can support TS 7.0.x — this PR's target range ^7.0.0 cannot be satisfied until TypeScript 7.1 exists and typescript-eslint adopts its new API. That's a substantially longer horizon than "wait for the next 8.x."

The blast radius is narrower than this PR implies

I tested each affected template on TS 7 directly, and only the Next.js pair is actually broken:

template	lint	build	verdict
template-react-ts	✅	✅ built in 317ms	fine on TS 7
template-vue-ts	✅	✅ built in 241ms	fine on TS 7
template-nextjs	❌	—	blocked
template-nextjs-ts	❌	—	blocked

That matches CI exactly: the only 6 red jobs are nextjs and nextjs-ts × {npm, yarn, pnpm}; all 6 react-ts/vue-ts jobs are green. The Next templates reach typescript-eslint transitively via eslint-config-next@16.3.3 → typescript-eslint@^8.46.0; the react/vue templates use flat config with globals and never load it.

Correcting my own framing on vue-tsc

I've been treating vue-tsc as a co-blocker across several updates. It does still crash on TS 7 — retested vue-tsc@3.3.11 (still latest, published 08-21) in a clean template-vue-ts:

Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/tsc' is not defined by
  "exports" in .../node_modules/typescript/package.json
    at resolveTscPath (.../node_modules/vue-tsc/index.js:73:43)

But no template script invokes it — the vue templates' scripts are lint (eslint .), build (vite build), test, format. vue-tsc sits in devDependencies unused, which is why vue-ts passes CI. So it's not a CI gate and never was; it's a "we ship a devDependency that crashes if a user runs it" hazard. Real, but a different and lesser problem than I'd implied, and it shouldn't hold the react/vue bumps.

Suggested way forward

Rather than keep this as a 6-week-old rolling tracker, I'd split it: land the TS 7 bump for the four non-Next templates (react-ts, react-ts-ssr, vue-ts, vue-ts-ssr — verified green above), and hold nextjs / nextjs-ts at ^5.9.3 behind a separate issue pinned to TypeScript 7.1. Renovate can be told to keep those two off TS 7 with a packageRules entry matching the two template paths, so it stops re-proposing a combination that can't pass.

The vue-tsc question (drop it, or pin it) is worth its own issue too, since it's user-visible in scaffolded projects regardless of what TypeScript version we pick.

Happy to open either issue and split the PR if that sounds right.

[BboyAkers]

All TS 7 changes are in now.....well except for Next.js I just realized. Resting my review

[dawsontoth]

Still blocked — and the wait condition is not "TS 7.1", as I'd previously said here

Disposition unchanged: the only red jobs are Generate nextjs* × {npm, yarn, pnpm}; all vanilla/react/react-ts/vue/vue-ts jobs and all 6 Test jobs are green. But I'd told this thread to watch for TypeScript 7.1. I checked that today and it does not hold, so flagging it before 7.1 lands and someone assumes this is ready.

The guard blocks all of TS 7.x, not just 7.0

Read the actual gate in typescript-eslint@8.68.0 (dist/index.js), the newest published:

const [versionMajor, _versionMinor] = ts.versionMajorMinor.split('.').map(Number);
if (versionMajor >= 7) {
  console.error([
    'typescript-eslint does not support TS 7.0.',
    ...
  ].join('\n'));
  throw new Error('typescript-eslint does not support TS 7.0.');
}

The predicate is versionMajor >= 7. It throws on 7.1, 7.2 and every future 7.x exactly as it throws on 7.0 — the message text says "7.0" but the check doesn't. And the peer is still capped at typescript: '>=4.8.4 <6.1.0' (unchanged through 8.68.0). The >=7.1 in that error string is a pointer to typescript-eslint's own tracking issue, not a version the guard admits.

So this unblocks when typescript-eslint ships a release that ports to the new API and relaxes both the guard and the peer range — not when TypeScript tags 7.1.

Why that port is a real piece of work

TS 7.1 dev builds now exist (typescript@next = 7.1.0-dev.20260826.1, dailies since 2026-08-16), so I compared the package surfaces. The exports maps of 7.0.2 and 7.1.0-dev are byte-identical:

".":               "./lib/version.cjs",
"./unstable/sync": "./dist/api/sync/api.js",
"./unstable/ast":  "./dist/ast/index.js",
...

• The replacement API already ships in 7.0 under typescript/unstable/* — it is not pending for 7.1.
• The root export is a version stub in both majors: require('typescript') gives exactly { version, versionMajorMinor }. Which is why a ts.versionMajorMinor read works while everything else consumers want is undefined.
• unstable/sync exposes a wholly different shape (API, Program, Checker, LanguageService, Snapshot, NodeHandle, …) — a rewrite for consumers, not a rename.

Recommendation unchanged, and it's the way to get value out of this now

Split the PR. Land TS 7 for the four non-Next templates — I've verified template-react-ts and template-vue-ts both lint and build clean on 7.0.2, matching CI — and hold the two Next templates behind a Renovate packageRules pin until typescript-eslint ships TS 7 support. Only eslint-config-next@16.3.3 → typescript-eslint@^8.46.0 is affected.

Also still true and still worth its own issue, separately from this PR: vue-tsc@3.3.11 crashes under TS 7 (ERR_PACKAGE_PATH_NOT_EXPORTED: './lib/tsc'), but no template script invokes it — it sits unused in devDependencies, which is why vue-ts is green. It's a "we ship a devDep that breaks if a user runs it" hazard, not a gate on this bump.

Holding at changes-requested for the Next templates only.