Build Options ​

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 transpile as little as possible:

• If the build.minify option is 'terser' and the installed Terser version is below 5.16.0, 'esnext' will be forced down to 'es2021'.
• In other cases, it will perform no transpilation at all.

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.

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.

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

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) }
• 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, default fileName is the name option of package.json, it can also be defined as function taking the format and entryAlias as arguments.

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.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.

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.