03 / 06

Discuss build options in Vite

Difficulty: 5/10
build config, performance optimization, environment variables

Vite provides comprehensive build options through both CLI flags and configuration file settings, allowing developers to control output directories, asset handling, code splitting, minification, source maps, and advanced features like library mode and multi-page app support

Vite's build system is designed to produce highly optimized static assets for production deployment. When you run vite build, Vite leverages Rollup under the hood (with Oxc in newer versions) to bundle your application, applying sophisticated optimizations like code splitting, tree-shaking, and asset minification. The build process is highly configurable through both command-line flags and the build section of your Vite configuration file, giving you fine-grained control over every aspect of the production output.

The vite build command accepts numerous flags that directly influence the build output. These options can be specified on the command line or through the configuration file, with CLI flags taking precedence.

Essential CLI Build Flags
  1. 1

    --target <target>: Sets the transpilation target (default: "modules"). Determines browser compatibility level for the final bundle.

  2. 2

    --outDir <dir>: Specifies the output directory (default: dist). All build artifacts are placed here.

  3. 3

    --assetsDir <dir>: Directory under outDir for static assets (default: "assets").

  4. 4

    --assetsInlineLimit <number>: Base64 inline threshold for static assets in bytes (default: 4096). Assets smaller than this are inlined as data URLs.

  5. 5

    --sourcemap [output]: Generate production source maps. Can be true, false, 'inline', or 'hidden'.

  6. 6

    --minify [minifier]: Enable/disable minification or specify minifier: 'esbuild' (default), 'terser', or false.

  7. 7

    --manifest [name]: Emit build manifest JSON mapping original filenames to hashed versions.

  8. 8

    --ssrManifest [name]: Emit SSR manifest JSON for style links and asset preload directives.

  9. 9

    --emptyOutDir: Force emptying outDir when it's outside the project root.

  10. 10

    -w, --watch: Rebuild when modules change on disk (enables Rollup watcher).

Vite's build.target option controls the browser compatibility level for the final bundle. Starting with Vite 6+, the default target is 'baseline-widely-available', which targets browsers in the Baseline Widely Available set as of 2026-01-01: Chrome 111+, Edge 111+, Firefox 114+, and Safari 16.4+. For legacy browser support, you can specify lower targets like 'es2015' or use the @vitejs/plugin-legacy to generate fallback chunks.

Basic Build Configuration Example

Beyond basic options, Vite provides sophisticated controls for optimizing your production build. These settings allow you to fine-tune how assets are processed, how code is split, and how dependencies are handled.

Advanced Build Options
  1. 1

    build.modulePreload: Controls module preload polyfill injection and dependency resolution. Can be customized with resolveDependencies function for fine-grained preload control.

  2. 2

    build.cssCodeSplit: When enabled (default), CSS imported in async chunks is preserved and fetched with the chunk. When disabled, all CSS is extracted into a single file.

  3. 3

    build.cssTarget: Allows setting a different browser target for CSS minification than for JavaScript, useful for browsers that support modern JS but not modern CSS features.

  4. 4

    build.cssMinify: Override CSS minification specifically. Defaults to 'lightningcss' for SSR builds in newer versions.

  5. 5

    build.rollupOptions: Direct access to Rollup configuration options for maximum flexibility (deprecated in favor of build.rolldownOptions in Vite 6+).

  6. 6

    build.commonjsOptions: Options passed to @rollup/plugin-commonjs for handling CommonJS dependencies.

  7. 7

    build.dynamicImportVarsOptions: Options for @rollup/plugin-dynamic-import-vars.

For library authors, Vite offers a dedicated library mode through the build.lib option. This mode configures Rollup specifically for library distribution, producing optimized bundles in multiple formats (ES, UMD, CJS) with proper externalization of dependencies. The library mode automatically handles CSS extraction, file naming, and global variable exposure for UMD builds.

Library Mode Configuration

Vite natively supports multi-page applications (MPAs) through configuration of multiple HTML entry points. Instead of a single index.html, you can specify multiple HTML files in build.rollupOptions.input. During development, you can navigate directly to these pages, and during build, Vite generates separate HTML files for each entry point with optimized assets.

Multi-Page App Configuration

Vite provides sophisticated code splitting capabilities through build.rollupOptions.output.manualChunks. This allows you to control how dependencies are grouped into separate chunks, optimizing caching and load performance. You can create custom chunking strategies based on module patterns, dependencies, or custom logic.

When building for integration with backend frameworks, Vite can generate manifest files (build.manifest and build.ssrManifest). These JSON files map original source filenames to their hashed production versions, enabling server frameworks to render correct asset links. The SSR manifest specifically helps determine style links and asset preload directives for server-side rendering.

The --watch flag enables Rollup's watcher, rebuilding whenever source files change. This is particularly useful during development of libraries or when integrating with other build systems. You can customize watch behavior through build.watch options, including settings for file system polling, ignore patterns, and build delay.

Vite includes a preview server command (vite preview) that serves the production build locally. This allows you to verify the built output before deployment, ensuring that all assets load correctly and the application behaves as expected in a production-like environment. The preview server respects the same base path and configuration as the production build.

Scenario Questions

0-2 years experience

  1. 1How would you configure Vite to output a production build that uses ES modules instead of a single bundle?
  2. 2If a teammate asks why the CSS is not minified after running `vite build`, what Vite build option would you check or adjust?
  3. 3What happens if you set `build.sourcemap` to true in a Vite project, and when would you enable it?

2-5 years experience

  1. 1You added a new library that ships both ESM and CommonJS. After running `vite build` the bundle size exploded. Which Vite build options could you tweak to control this, and why?
  2. 2During a CI run the build fails with an error about missing environment variables. How would you use Vite's build configuration to inject different variables for staging vs production?
  3. 3Explain why enabling `build.minify: false` caused a regression in page load time, and how you would decide whether to keep minification on.

5-8 years experience

  1. 1Our monorepo shares components across multiple Vite apps. How would you configure the `build.rollupOptions` and `optimizeDeps` to avoid duplicate code and keep build times low?
  2. 2We need to serve pre‑compressed assets (gzip/brotli) from a CDN. Which Vite build options and plugins would you use, and what trade‑offs should you consider for cache‑busting?
  3. 3A client reports that the production build is missing some dynamic imports after upgrading Vite. Walk through how you would debug the issue using Vite's build configuration.

8+ years experience

  1. 1The company is migrating a legacy Webpack build to Vite across dozens of services. What high‑level strategy would you propose for standardizing build options, handling edge‑case plugins, and ensuring consistent output?
  2. 2How would you design a shared Vite build configuration library that can be consumed by both frontend and backend teams, balancing flexibility with enforceable performance standards?
  3. 3When planning long‑term maintenance, what policies would you set around `build.target`, `esbuild` vs `terser` minifiers, and polyfill handling to future‑proof the codebase?

Follow-up Questions

  • Can you walk me through how you would verify the output after changing a build option?
  • What impact does the `target` setting have on older browsers?
  • How would you measure whether a build optimization actually improves performance?
Share

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.