init: use TypeScript 7 in every template

[robobun]

Follow-up to #33265, which put every bun init template on TypeScript 6. @alii asked for the templates to use TypeScript 7 instead.

Problem

• typescript@7.0.2 has been the npm latest dist-tag since July 8; the templates still pin "typescript": "^6", so a fresh bun init project gets 6.0.3.
• Written in three places: init_command.rs:780 (the blank and library templates write the peerDependencies entry), the three react template package.json files (embedded into the binary with include_bytes!), and the matching example in docs/quickstart.mdx.

Fix

• bun init writes "typescript": "^7"; the react, react-tailwind and react-shadcn templates declare the same range; docs/quickstart.mdx matches the generated package.json.
• The three template bun.lock files are regenerated from scratch. They now resolve typescript@7.0.2 plus its twenty @typescript/typescript-<os>-<arch> optional dependencies, and pick up the patch and minor releases of the other template dependencies published since July. bun install --frozen-lockfile passes in all three directories. (A plain bun install does not move them: see the note below.)
• All four templates typecheck (tsc --noEmit) and build (bun run build) under 7.0.2 with the existing tsconfig.json files; no template source changed.
• Verified with test/cli/init/init.test.ts: the per-template installs TypeScript 7, typechecks, and builds test now asserts the installed major is 7, and the ^7 range is asserted for every template. Against an unpatched bun, 9 of the 15 tests in the file fail (typescript resolves to 6.0.3); with this change all 15 pass.
• The typecheck step now runs node_modules/typescript/bin/tsc under the bun build under test instead of nodeExe() ?? bunExe(). TypeScript 7's bin/tsc is a small ESM shim that execs the native compiler, so the reason to prefer node (tsc under a debug bun was slow) is gone, and this is what bunx tsc runs on a machine without node. The shim plus the shadcn template typecheck takes about 1.1s under the debug build here.

Background

• TypeScript 7 is the Go port of the compiler. The typescript npm package is now a thin wrapper: bin/tsc resolves @typescript/typescript-<platform> (one optional dependency per platform, the same layout esbuild uses) and execs the binary in it. require("typescript") only exposes the version; the JS compiler API is not part of the package. Nothing in the templates uses that API, only tsc and editors.
• The template bun.lock files are not embedded in the binary. bun init runs a fresh bun install against the template's package.json, so users get whatever ^7 resolves to at that time; the checked-in lockfiles exist so the template directories can be installed and verified as-is.

Note on regenerating the lockfiles

Changing the root peerDependencies range and running bun install in a template directory kept typescript@6.0.3 in the lockfile (with warn: incorrect peer dependency "typescript@6.0.3"), and bun update typescript kept it too while rewriting the range in package.json back to ^6.0.3; only bun update --latest typescript or deleting the lockfile moves it. A regular devDependencies entry re-resolves as expected. That is an install bug independent of this change and is being tracked separately; the lockfiles here were regenerated by deleting them and running bun install.

---

no test proof · iteration 1 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/cli/init/init.test.ts

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Limit details: You’ve used all 5 included reviews currently available under your plan.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4e7fc79e-68be-4d3e-808f-1f1e544cd2bc

📥 Commits

Reviewing files that changed from the base of the PR and between aec33f5 and e5f907d.

⛔ Files ignored due to path filters (3)

• src/runtime/cli/init/react-app/bun.lock is excluded by !**/*.lock
• src/runtime/cli/init/react-shadcn/bun.lock is excluded by !**/*.lock
• src/runtime/cli/init/react-tailwind/bun.lock is excluded by !**/*.lock

📒 Files selected for processing (6)

• docs/quickstart.mdx
• src/runtime/cli/init/react-app/package.json
• src/runtime/cli/init/react-shadcn/package.json
• src/runtime/cli/init/react-tailwind/package.json
• src/runtime/cli/init_command.rs
• test/cli/init/init.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Reproduced: with the released bun, bun init -y / --react / --react=tailwind / --react=shadcn all install typescript@6.0.3; USE_SYSTEM_BUN=1 bun test test/cli/init/init.test.ts fails 9 of 15 tests on this branch. With this change, bun bd test test/cli/init/init.test.ts passes all 15, and each template typechecks and builds under typescript@7.0.2.

Fix: this PR (#39341). Requested by @alii as a follow-up to #33265.

[robobun]

Thanks. Nothing outstanding on the review side; CI for 02c2f20 is still running (https://buildkite.com/bun/bun/builds/99347). I will follow up here only if a lane turns up something related to this change.

[claude]

LGTM — mechanical ^6 → ^7 bump across the four template sources, docs, and tests, following the same shape as #33265.

What was reviewed:

• Grepped src/ and docs/ for any remaining typescript.*\^6 — none; all four write sites (init_command.rs + three embedded package.json files) and the quickstart example are updated in lockstep.
• Test assertions flipped to ^7 / toStartWith("7.") for every template; the nodeExe → bunExe() swap for the tsc shim is sound (TS7 bin/tsc execs a native binary, so the debug-bun-slowness rationale no longer applies) and the now-unused nodeExe import is removed.
• The regenerated bun.lock files are not embedded in the binary; incidental patch bumps (react 19.2.7→19.2.8, radix-ui, etc.) stay within the existing package.json ranges.

Extended reasoning...

Overview

This PR bumps the TypeScript peer dependency in every bun init template from ^6 to ^7, mirroring the structure of #33265 (the ^5→^6 bump). The change touches: one byte literal in init_command.rs (the blank/library template writer), the three embedded react template package.json files, the matching example in docs/quickstart.mdx, the three template bun.lock files (regenerated, not shipped), and test/cli/init/init.test.ts (assertions updated to ^7, plus the tsc invocation switched from nodeExe() ?? bunExe() to bunExe()).

Security risks

None. This is a version-range string change in scaffolding templates. No parsing, no auth, no user input handling was touched. The regenerated lockfiles pull known packages (typescript@7.0.2 and its per-platform native binaries, plus in-range patch bumps of react/radix-ui/etc.) and are not embedded in the binary — bun init runs a fresh install against the package.json range.

Level of scrutiny

Low. This is a mechanical config/version bump with a clear precedent PR. The only non-trivial change is the test switching the tsc runner from nodeExe() ?? bunExe() to bunExe(); the rationale is well-documented in both the PR description and the updated test comment (TS7 bin/tsc is a tiny ESM shim that execs the native Go compiler, so the original "debug bun runs tsc slowly" concern no longer applies, and this now exercises the same path bunx tsc uses). The dead nodeExe import is correctly removed.

Other factors

• Verified no stray typescript.*\^6 references remain in src/ or docs/.
• No CODEOWNERS entries cover the touched paths.
• The existing per-template installs TypeScript N, typechecks, and builds test asserts the installed major and runs tsc --noEmit + bun run build end-to-end for all four templates, so CI will catch any tsconfig incompatibility with TS7.
• The PR description states 9/15 tests fail on unpatched bun and all 15 pass with the change, satisfying the fails-for-the-right-reason bar.

[robobun]

^{Updated 1:56 AM PT - Aug 16th, 2026}

@robobun, your commit e5f907d is building: #99368

[claude]

LGTM — mechanical ^6 → ^7 bump mirroring #33265.

What was reviewed:

• Confirmed all five write sites are covered (init_command.rs, three template package.json files, docs/quickstart.mdx); grep found no remaining typescript.*^6 in src/ or docs/.
• Test assertions updated in place for every template; nodeExe import removed alongside its only use.
• Template bun.lock files are regenerated, not hand-edited, and are not embedded in the binary.

Extended reasoning...

Overview

This PR bumps the TypeScript peer-dependency range in every bun init template from ^6 to ^7, following #33265 which did the identical 5→6 bump. The change touches one string literal in init_command.rs (the blank/library template writer), three embedded template package.json files, the matching example in docs/quickstart.mdx, three regenerated bun.lock files (not shipped in the binary), and the existing test/cli/init/init.test.ts assertions. The only non-string-literal behavior change is swapping nodeExe() ?? bunExe() for bunExe() when running tsc in the test, with a clear comment explaining that TS7's bin/tsc is a native-exec shim so the debug-bun-is-slow rationale no longer applies.

Security risks

None. No user input handling, no auth/crypto/permissions. The lockfiles are developer-facing verification artifacts that bun init does not ship or read; users get a fresh bun install against ^7.

Level of scrutiny

Low. This is a version-string bump across a fixed, enumerable set of sites, directly mirroring a prior PR that did the same thing for the previous major. The bug-hunting system found nothing. I grepped src/ and docs/ for any remaining typescript.*^6 and found none, so the sibling-site coverage is complete. The lockfile diffs are large but auto-generated (delete + bun install).

Other factors

The PR description documents that all four templates typecheck and build under 7.0.2, that USE_SYSTEM_BUN=1 fails 9/15 tests while the patched build passes 15/15, and that bun install --frozen-lockfile passes in each template directory. The test change keeps the existing test.each matrix and updates assertions rather than adding a new file, per repo conventions. The removed nodeExe import matches its removed sole use. A maintainer explicitly requested this follow-up.