Build Options

Unless noted, the options in this section are only applied to build.

build.target

• Type: string | string[]
• Default: 'modules'
• Related: Browser Compatibility

Browser compatibility target for the final bundle. The default value is a Vite special value, 'modules', which targets browsers with native ES Modules, native ESM dynamic import, and import.meta support. Vite will replace 'modules' to ['es2020', 'edge88', 'firefox78', 'chrome87', 'safari14']

Another special value is 'esnext' - which assumes native dynamic imports support and will only perform minimal transpiling.

The transform is performed with esbuild and the value should be a valid esbuild target option. Custom targets can either be an ES version (e.g. es2015), a browser with version (e.g. chrome58), or an array of multiple target strings.

Note the build will fail if the code contains features that cannot be safely transpiled by esbuild. See esbuild docs for more details.

build.modulePreload

• Type: boolean | { polyfill?: boolean, resolveDependencies?: ResolveModulePreloadDependenciesFn }
• Default: { polyfill: true }

By default, a module preload polyfill is automatically injected. The polyfill is auto injected into the proxy module of each index.html entry. If the build is configured to use a non-HTML custom entry via build.rollupOptions.input, then it is necessary to manually import the polyfill in your custom entry:

import 'vite/modulepreload-polyfill'

Note: the polyfill does not apply to Library Mode. If you need to support browsers without native dynamic import, you should probably avoid using it in your library.

The polyfill can be disabled using { polyfill: false }.

The list of chunks to preload for each dynamic import is computed by Vite. By default, an absolute path including the base will be used when loading these dependencies. If the base is relative ('' or './'), import.meta.url is used at runtime to avoid absolute paths that depend on the final deployed base.

There is experimental support for fine grained control over the dependencies list and their paths using the resolveDependencies function. Give Feedback. It expects a function of type ResolveModulePreloadDependenciesFn:

type ResolveModulePreloadDependenciesFn = (
  url: string,
  deps: string[],
  context: {
    hostId: string
    hostType: 'html' | 'js'
  },
) => string[]

The resolveDependencies function will be called for each dynamic import with a list of the chunks it depends on, and it will also be called for each chunk imported in entry HTML files. A new dependencies array can be returned with these filtered or more dependencies injected, and their paths modified. The deps paths are relative to the build.outDir. The return value should be a relative path to the build.outDir.

modulePreload: {
  resolveDependencies: (filename, deps, { hostId, hostType }) => {
    return deps.filter(condition)
  },
},

The resolved dependency paths can be further modified using experimental.renderBuiltUrl.

build.polyfillModulePreload

• Type: boolean
• Default: true
• Deprecated use build.modulePreload.polyfill instead

Whether to automatically inject a module preload polyfill.

build.outDir

• Type: string
• Default: dist

Specify the output directory (relative to project root).

build.assetsDir

• Type: string
• Default: assets

Specify the directory to nest generated assets under (relative to build.outDir. This is not used in Library Mode).

build.assetsInlineLimit

• Type: number | ((filePath: string, content: Buffer) => boolean | undefined)
• Default: 4096 (4 KiB)

Imported or referenced assets that are smaller than this threshold will be inlined as base64 URLs to avoid extra http requests. Set to 0 to disable inlining altogether.

If a callback is passed, a boolean can be returned to opt-in or opt-out. If nothing is returned the default logic applies.

Git LFS placeholders are automatically excluded from inlining because they do not contain the content of the file they represent.

Note

If you specify build.lib, build.assetsInlineLimit will be ignored and assets will always be inlined, regardless of file size or being a Git LFS placeholder.

build.cssCodeSplit

• Type: boolean
• Default: true

Enable/disable CSS code splitting. When enabled, CSS imported in async JS chunks will be preserved as chunks and fetched together when the chunk is fetched.

If disabled, all CSS in the entire project will be extracted into a single CSS file.

Note

If you specify build.lib, build.cssCodeSplit will be false as default.

build.cssTarget

• Type: string | string[]
• Default: the same as build.target

This option allows users to set a different browser target for CSS minification from the one used for JavaScript transpilation.

It should only be used when you are targeting a non-mainstream browser. One example is Android WeChat WebView, which supports most modern JavaScript features but not the #RGBA hexadecimal color notation in CSS. In this case, you need to set build.cssTarget to chrome61 to prevent vite from transform rgba() colors into #RGBA hexadecimal notations.

build.cssMinify

• Type: boolean | 'esbuild' | 'lightningcss'
• Default: the same as build.minify for client, 'esbuild' for SSR

This option allows users to override CSS minification specifically instead of defaulting to build.minify, so you can configure minification for JS and CSS separately. Vite uses esbuild by default to minify CSS. Set the option to 'lightningcss' to use Lightning CSS instead. If selected, it can be configured using css.lightningcss.

build.sourcemap

• Type: boolean | 'inline' | 'hidden'
• Default: false

Generate production source maps. If true, a separate sourcemap file will be created. If 'inline', the sourcemap will be appended to the resulting output file as a data URI. 'hidden' works like true except that the corresponding sourcemap comments in the bundled files are suppressed.

build.rollupOptions

• Type: RollupOptions

Directly customize the underlying Rollup bundle. This is the same as options that can be exported from a Rollup config file and will be merged with Vite's internal Rollup options. See Rollup options docs for more details.

build.commonjsOptions

• Type: RollupCommonJSOptions

Options to pass on to @rollup/plugin-commonjs.

build.dynamicImportVarsOptions

• Type: RollupDynamicImportVarsOptions
• Related: Dynamic Import

Options to pass on to @rollup/plugin-dynamic-import-vars.

build.lib

• Type: { entry: string | string[] | { [entryAlias: string]: string }, name?: string, formats?: ('es' | 'cjs' | 'umd' | 'iife')[], fileName?: string | ((format: ModuleFormat, entryName: string) => string), cssFileName?: string }
• Related: Library Mode

Build as a library. entry is required since the library cannot use HTML as entry. name is the exposed global variable and is required when formats includes 'umd' or 'iife'. Default formats are ['es', 'umd'], or ['es', 'cjs'], if multiple entries are used.

fileName is the name of the package file output, which defaults to the "name" in package.json. It can also be defined as a function taking the format and entryName as arguments, and returning the file name.

If your package imports CSS, cssFileName can be used to specify the name of the CSS file output. It defaults to the same value as fileName if it's set a string, otherwise it also falls back to the "name" in package.json.

vite.config.js

import { defineConfig } from 'vite'

export default defineConfig({
  build: {
    lib: {
      entry: ['src/main.js'],
      fileName: (format, entryName) => `my-lib-${entryName}.${format}.js`,
      cssFileName: 'my-lib-style',
    },
  },
})

build.manifest

• Type: boolean | string
• Default: false
• Related: Backend Integration

When set to true, the build will also generate a .vite/manifest.json file that contains a mapping of non-hashed asset filenames to their hashed versions, which can then be used by a server framework to render the correct asset links. When the value is a string, it will be used as the manifest file name.

build.ssrManifest

• Type: boolean | string
• Default: false
• Related: Server-Side Rendering

When set to true, the build will also generate an SSR manifest for determining style links and asset preload directives in production. When the value is a string, it will be used as the manifest file name.

build.ssr

• Type: boolean | string
• Default: false
• Related: Server-Side Rendering

Produce SSR-oriented build. The value can be a string to directly specify the SSR entry, or true, which requires specifying the SSR entry via rollupOptions.input.

build.emitAssets

• Type: boolean
• Default: false

During non-client builds, static assets aren't emitted as it is assumed they would be emitted as part of the client build. This option allows frameworks to force emitting them in other environments build. It is responsibility of the framework to merge the assets with a post build step.

build.ssrEmitAssets

• Type: boolean
• Default: false

During the SSR build, static assets aren't emitted as it is assumed they would be emitted as part of the client build. This option allows frameworks to force emitting them in both the client and SSR build. It is responsibility of the framework to merge the assets with a post build step. This option will be replaced by build.emitAssets once Environment API is stable.

build.minify

• Type: boolean | 'terser' | 'esbuild'
• Default: 'esbuild' for client build, false for SSR build

Set to false to disable minification, or specify the minifier to use. The default is esbuild which is 20 ~ 40x faster than terser and only 1 ~ 2% worse compression. Benchmarks

Note the build.minify option does not minify whitespaces when using the 'es' format in lib mode, as it removes pure annotations and breaks tree-shaking.

Terser must be installed when it is set to 'terser'.

npm add -D terser

build.terserOptions

• Type: TerserOptions

Additional minify options to pass on to Terser.

In addition, you can also pass a maxWorkers: number option to specify the max number of workers to spawn. Defaults to the number of CPUs minus 1.

build.write

• Type: boolean
• Default: true

Set to false to disable writing the bundle to disk. This is mostly used in programmatic build() calls where further post processing of the bundle is needed before writing to disk.

build.emptyOutDir

• Type: boolean
• Default: true if outDir is inside root

By default, Vite will empty the outDir on build if it is inside project root. It will emit a warning if outDir is outside of root to avoid accidentally removing important files. You can explicitly set this option to suppress the warning. This is also available via command line as --emptyOutDir.

build.copyPublicDir

• Type: boolean
• Default: true

By default, Vite will copy files from the publicDir into the outDir on build. Set to false to disable this.

build.reportCompressedSize

• Type: boolean
• Default: true

Enable/disable gzip-compressed size reporting. Compressing large output files can be slow, so disabling this may increase build performance for large projects.

build.chunkSizeWarningLimit

• Type: number
• Default: 500

Limit for chunk size warnings (in kB). It is compared against the uncompressed chunk size as the JavaScript size itself is related to the execution time.

build.watch

• Type: WatcherOptions| null
• Default: null

Set to {} to enable rollup watcher. This is mostly used in cases that involve build-only plugins or integrations processes.

Using Vite on Windows Subsystem for Linux (WSL) 2

There are cases that file system watching does not work with WSL2. See server.watch for more details.