build: align Vite 8 bundler config

[southpolesteve]

Summary

• bump the workspace catalog and vinext peer range to the current Vite 8 plugin-rsc/plugin-react releases
• emit rolldownOptions on Vite 8 while still honoring user-supplied legacy build.rollupOptions
• switch client chunking to Rolldown codeSplitting on Vite 8 and update tests to accept both config shapes

Testing

• pnpm test tests/build-optimization.test.ts
• pnpm test tests/pages-router.test.ts -t "suppresses MODULE_LEVEL_DIRECTIVE warnings from Rollup|preserves user-supplied build.rollupOptions.onwarn"
• pnpm test tests/tsconfig-paths-vite8.test.ts
• pnpm run build

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@599

commit: 8a2b6b7

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original

[james-elicx]

/bigbonk review

[ask-bonk]

Clean abstraction for the Vite 7/8 bundler config split. All CI green, deploy previews healthy. A few observations:

What looks good

• The getBuildBundlerOptions / withBuildBundlerOptions / getClientOutputConfigForVite trio is a clean seam — centralizes the version branching so call sites stay readable.
• getBuildBundlerOptions correctly prefers rolldownOptions over rollupOptions when reading user config, so users supplying the legacy key on Vite 8 still get their onwarn picked up.
• The clientCodeSplittingConfig mapping from Rollup's manualChunks + experimentalMinChunkSize to Rolldown's codeSplitting.groups[].name + codeSplitting.minSize looks correct.
• Test helpers (getBuildBundlerOptions, getEnvBuildBundlerOptions) make assertions version-agnostic without losing coverage — the if (output.codeSplitting) branch in the chunk sizing test is a nice touch.
• The "preserves user-supplied build.rollupOptions.onwarn" test passes rollupOptions as mock input, which validates the legacy fallback path in getBuildBundlerOptions. Good.

Minor observations (non-blocking)

1. Duplicate withBuildBundlerOptions in cli.ts: The CLI defines its own local closure (bundlerOptions: Record<string, unknown>) => ... instead of importing the one from index.ts. The signatures differ slightly (Record<string, unknown> vs VinextBuildBundlerOptions), so I understand why — the CLI doesn't have access to the Vite type for VinextBuildBundlerOptions at that point. Fine for now, but if this grows, consider exporting a loosely-typed version from index.ts.

2. clientCodeSplittingConfig.groups[].name returns null: The name function returns clientManualChunks(moduleId) ?? null. I assume Rolldown's codeSplitting.groups[].name treats null as "don't assign a custom name" (fall through to default splitting). Worth a quick sanity check that Rolldown doesn't treat null differently from undefined here, but given all E2E and deploy previews pass, this is clearly working.

3. No test for user-supplied build.rolldownOptions.onwarn: The existing test passes { build: { rollupOptions: { onwarn } } } which validates the legacy path. A parallel test with { build: { rolldownOptions: { onwarn } } } would cover the Vite 8 path directly — not blocking since getBuildBundlerOptions prefers rolldownOptions first, so the logic is exercised, but it would be a nice addition for completeness.

Everything else — version bumps, lock file cleanup, peer dep range — looks correct. All 30 CI checks pass including full E2E suites and deploy previews.

[ask-bonk]

Review posted and PR approved. Here's a summary of the review:

Approved PR #599 — The PR cleanly abstracts the Vite 7/8 bundler config divergence (rollupOptions vs rolldownOptions, manualChunks vs codeSplitting) into three centralized functions. All 30 CI checks pass including full E2E suites and deploy previews.

Three non-blocking observations were noted:

1. The CLI duplicates withBuildBundlerOptions as a local closure instead of importing from index.ts (due to type signature differences — fine for now)
2. The Rolldown codeSplitting.groups[].name function returns null for unmatched modules — works in practice but worth verifying Rolldown's null vs undefined semantics
3. Missing a parallel test for user-supplied build.rolldownOptions.onwarn (only rollupOptions legacy path is tested)

github run