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.