Vite advanced config

Vite Configuration for React

Purpose

This skill performs reproducible triage of a React project's vite.config.js, .ts, .mjs, or .mts. It looks for explicitly risky options or settings that deserve measurement; it does not turn healthy Vite defaults into “problems.” The report is advisory: only a real build and loading profile can confirm a performance gain.

Primary compatibility: Node 22.13+, Vite 8, and current React. The guidance also applies to Vite 7 (Rollup) and React 18 projects; when the version cannot be determined, the script does not assume a migration.

Memory and patterns

Read the local MEMORY.md and follow ../.shared/SKILL-MEMORY-PROTOCOL.md; use node "<skills-root>/.shared/src/memory-cli.js" append ... for actionable results. The utility validates, renumbers, and retains up to 12 entries.

Before making decisions influenced by existing code, follow ../.shared/PATTERN-LEARNING-PROTOCOL.md and query the repository catalog with node "<skills-root>/.shared/src/pattern-learning/pattern-cli.js" query ...; after confirming a new or refined pattern in the code, consolidate it with node "<skills-root>/.shared/src/pattern-learning/pattern-cli.js" upsert ....

When to use

• Review build, server, and optimizeDeps before an infrastructure change.
• Investigate published source maps, exposed development hosts, or redundant pre-bundling.
• Plan migration of build.rollupOptions or manualChunks from Vite 7 to Vite 8 and Rolldown.
• Compare a minifier, chunk splitting, or target using a reproducible production artifact.

When not to use

• The bottleneck is a re-render or React component; use the component, memoization, or state skills.
• The project does not use Vite.
• The question requires concluding that one option is faster without a build and comparable metrics.

Recommended workflow

1. Record the commit, Node and Vite versions, target browser, and build command.
2. Run the auditor in JSON mode with --dry-run.
3. Review each finding against mode-specific configuration (development or production) and network context.
4. Make one change at a time. Build the same fixture with cold and warm caches for at least three repetitions.
5. Compare median time, raw, gzip, and Brotli bytes, and the initial browser flow. Record failures and variance as well; a structural or readability change without a measurable difference is not a performance gain.

node "<skill-dir>/scripts/audit-vite-config.js" ./app --format json --dry-run
node "<skill-dir>/scripts/audit-vite-config.js" ./app --output validation-results/vite --force

--output writes both Markdown and JSON, and the JSON contains schemaVersion: 1. All other output behavior follows the shared CLI contract in ../.shared/README.md.

What the auditor reports

• Static build.sourcemap: true: confirm whether the map belongs in the production artifact and whether publishing sources is acceptable.
• build.minify: "terser": an informational signal to measure build cost and size against the version's default minifier (esbuild in Vite 7, Oxc in Vite 8); terser is not automatically better.
• server.allowedHosts: true or ['*']: exposure risk; prefer explicit hosts.
• server.host: true, 0.0.0.0, or ::: the server is reachable through every interface; combine deliberate exposure with an allowlist.
• optimizeDeps.include containing react or react-dom: usually redundant; retain it only for a reproducible discovery error.
• build.rollupOptions when package.json declares Vite 8 or later: a Rolldown compatibility signal. Rollup remains valid in Vite 7 and is not reported.

The auditor does not report the absence of minify, sourcemap, manualChunks, optimizeDeps, cssCodeSplit, or treeshake: those defaults are valid, and manual code splitting can worsen caching and loading. It also does not assume that a resolve.extensions list or plugin is required.

Vite 7/Rollup and Vite 8/Rolldown

Read the declared vite version before changing APIs. Keep rollupOptions in Vite 7 when the result is measured. In Vite 8, treat the finding as a planned migration: validate bundle equivalence and only then adopt Rolldown options supported by the installed version. Do not remove server.host or server.allowedHosts during this migration.

Known limitations

• Analysis is static and deliberately conservative: spreads, imports, and values calculated outside the file produce an informational signal or require manual review.
• The script does not execute the configuration, know which mode will be used, or measure chunks. Conditional values are not classified as static risks.
• Bundle size, TTFB, LCP, parse and execution time, and request count must be collected through the build or browser; the scanner promises no gain percentage.

Files

• scripts/audit-vite-config.js: CLI and TypeScript AST analysis.
• config/vite.config.recommended.js: small, safe baseline without assumed manualChunks.
• examples/before/ and examples/after/: teaching fixture; the “after” example is not a universal recipe.
• checklists/vite-checklist.md: manual review and measurement protocol.

Constraints

• Do not add dependencies to the audited project.
• Do not publish source maps, expose hosts, or add manual chunks without justification and measurement.
• Preserve deliberate security configuration and record environment limitations.