Bundler config advice that doesn't match the installed major version is worse than no advice — it produces a config diff that silently no-ops, throws at build time, or (worst case) applies to the wrong bundler engine entirely. Vite ships two build engines depending on version and config shape (Rollup-backed rollupOptions, or Rolldown-backed rolldownOptions), and Vite 8 removed the object form of manualChunks outright. This skill reviews Vite/Webpack build and chunking configuration itself — the config file, not the resulting bundle bytes — and treats the target bundler's exact major version as a required input, not an assumption, before proposing any config diff.
Use this skill when the user asks to:
\nbuild.rollupOptions/build.rolldownOptions or Webpack optimization.splitChunks chunking configuration,sideEffects field interaction with the bundler, barrel-file re-exports defeating static analysis) rather than to source-code side effects,bundle-budget-code-splitting-review for that; this skill reviews the bundler config mechanism, not the budget methodology or split-boundary decision.sideEffects: false correctness on a specific package — hand off to tree-shaking-dead-code-review for that; this skill only flags build-config patterns (barrel imports, module-format mismatches) that are known to defeat tree-shaking, it does not verify the outcome.tsc-only builds, esbuild/Rolldown used as a library outside Vite/Webpack) — different config surface, not in scope here.Vite's build-engine and chunking API surface changed between major versions — do not prescribe a config from memorized training data.
\nToolSearch with query \"context7\" (or \"select:mcp__Context7__resolve-library-id,mcp__Context7__query-docs\") to load the Context7 tools if not already loaded this session.mcp__Context7__resolve-library-id for each bundler in scope (/vitejs/vite, Webpack, /rollup/rollup, and /rolldown/rolldown if the project's Vite build is Rolldown-backed) before prescribing any chunking configuration.mcp__Context7__query-docs for the specific mechanism — e.g. \"rollupOptions.output.manualChunks vs rolldownOptions.output.codeSplitting\", \"splitChunks cacheGroups defaults\", \"manualChunks object form vs function form\" — before ruling on it. Do this per review; do not reuse a prior session's memory of bundler internals.updated date:\nbuild.rollupOptions.output.manualChunks was removed, and the function form was deprecated; the replacement is build.rolldownOptions.output.codeSplitting, which takes a groups array of { name, test } entries (Rolldown's declarative chunk-grouping API). Do not hand a project on that config path a manualChunks: { vendor: [...] } object-form snippet — it will not apply.rollupOptions) continues to support both the object form and function form of output.manualChunks per Rollup's own configuration docs — the removal is specific to Vite's option surface and its migration path toward Rolldown, not a Rollup-wide deprecation. Confirm which bundler engine actually processes the config (rollupOptions vs rolldownOptions key) before applying either party's rules.splitVendorChunkPlugin that composes with function-form manualChunks but explicitly logs a warning and no-ops when combined with the object form — treat \"vendor chunk isn't splitting and there's a console warning about splitVendorChunk\" as a symptom of this specific interaction, not a generic bug report.optimization.splitChunks surface (cacheGroups, chunks: 'all' | 'async' | 'initial', minSize, maxInitialRequests) is comparatively stable across recent majors per Context7-grounded docs, including its documented defaults (minSize: 20000, defaultVendors/default cache groups with priority: -10/-20) — still confirm the installed Webpack major before asserting a specific default, since defaults have shifted across major versions historically.official_docs and mark the claim documentation-based (Context7 unavailable) rather than presenting it as freshly verified.rollupOptions vs rolldownOptions) the project's own config already uses before proposing a diff — these are two different bundler engines with two different chunking APIs, and giving the wrong era's config is a concrete, verified failure, not a style choice.index.ts re-export) imports and wildcard imports of large libraries (icon sets, date libraries, utility libraries) as build-config-relevant tree-shaking risks when the project's module format or bundler settings can't statically resolve them — name the specific named/subpath-import fix, and hand off to tree-shaking-dead-code-review to verify the byte-level outcome.manualChunks/codeSplitting/cacheGroups), not an application-code defect — do not propose restructuring import statements to solve what a config change solves more directly.bundle-budget-code-splitting-review.manualChunks object-form removal) rather than error.Load these only when needed:
\nrollupOptions.output.manualChunks or rolldownOptions.output.codeSplitting, or diagnosing which bundler engine a Vite config actually invokes.optimization.splitChunks, cacheGroups, or runtimeChunk configuration.Return, at minimum:
\nrollupOptions or rolldownOptions) the guidance targets,live evidence, user-provided sanitized evidence, documentation-based, or inference),bundle-budget-code-splitting-review or tree-shaking-dead-code-review if the user's actual question is budget-setting or tree-shaking verification rather than config review.