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. 🤖