CSS bundling in library mode
In library mode, if the entry file imports CSS, it will be bundled as a single CSS file in the dist folder. The CSS filename defaults to `build.lib.fileName` but can be changed with `build.lib.cssFileName`.
build
82 notes in this subject, read out of this brain and free to use. This is page 2 of 2.
Exporting CSS file from library
CSS files bundled in library mode can be exported in package.json under the `exports` field, allowing users to import them separately.
File extensions for package.json without type:module
If package.json does not contain `"type": "module"`, Vite generates different file extensions for Node.js compatibility: `.js` becomes `.mjs` and `.cjs` becomes `.js`.
Environment variables in library mode
In library mode, all `import.meta.env.*` usage is statically replaced when building for production, but `process.env.*` usage is not replaced, allowing consumers to dynamically change it. Use `define: { 'process.env.NODE_ENV': '"production"' }` to statically replace process.env, or use esm-env for better bundler compatibility.
Advanced base options with experimental.renderBuiltUrl
The `experimental.renderBuiltUrl` function allows advanced base path control when deployed assets and public files are in different paths. It receives `filename` and a context object with `hostId`, `hostType`, and `type` properties. It should return either a URL string or an object with `runtime` or `relative` properties.
renderBuiltUrl context parameters
The `experimental.renderBuiltUrl` function receives a context object with: `hostId` (the file using the URL), `hostType` (either 'js' or 'html'), and `type` (either 'public' or another asset type).
renderBuiltUrl return values
The `experimental.renderBuiltUrl` function can return: a URL string (decoded, Vite will encode it), an object with `runtime` property (string rendered as-is, handle encoding yourself), or an object with `relative: true` for relative URLs.
renderBuiltUrl filename parameter encoding
The `filename` parameter passed to `experimental.renderBuiltUrl` is a decoded URL. If the function returns a URL string, it should also be decoded; Vite handles encoding automatically.
Example vite:preloadError handler
window.addEventListener('vite:preloadError', (event) => { window.location.reload() })
Example build.lib multiple entries config
export default defineConfig({ build: { lib: { entry: { 'my-lib': resolve(import.meta.dirname, 'lib/main.js'), secondary: resolve(import.meta.dirname, 'lib/secondary.js') }, name: 'MyLib' }, rolldownOptions: { external: ['vue'], output: { globals: { vue: 'Vue' } } } } })
Example multi-page app config
export default defineConfig({ input: { main: resolve(import.meta.dirname, 'index.html'), nested: resolve(import.meta.dirname, 'nested/index.html') } })
Example renderBuiltUrl basic usage
experimental: { renderBuiltUrl(filename, { hostType }) { if (hostType === 'js') { return { runtime: `window.__toCdnUrl(${JSON.stringify(filename)})` } } else { return { relative: true } } } }
Example renderBuiltUrl with asset types
experimental: { renderBuiltUrl(filename, { hostId, hostType, type }) { if (type === 'public') { return 'https://www.domain.com/' + filename } else if (path.extname(hostId) === '.js') { return { runtime: `window.__assetsPath(${JSON.stringify(filename)})` } } else { return 'https://cdn.domain.com/assets/' + filename } } }
Multi-page app with multiple HTML entry points
For multi-page apps, specify multiple .html files as entry points using the `input` config with an object mapping entry names to resolved HTML file paths. Vite ignores the entry names for HTML files and respects the resolved file path when generating HTML assets in the dist folder.
Default build entry point
By default, Vite uses `<root>/index.html` as the build entry point when running the `vite build` command.
Default browser compatibility targets
By default, the production bundle targets minimum browser versions compatible with Baseline Widely Available as of a date fixed for each major release. For the current major version, the default target is Chrome >=111, Edge >=111, Firefox >=114, and Safari >=16.4.
Minimum browser support for ESM dynamic import and import.meta
Vite requires minimum browser support ranges for native ESM dynamic import and import.meta, regardless of the build.target setting. These minimums are Chrome >=64, Firefox >=67, Safari >=11.1, and Edge >=79.
Vite does not provide polyfills by default
By default, Vite only handles syntax transforms and does not cover polyfills. Legacy browsers can be supported via @vitejs/plugin-legacy, which automatically generates legacy chunks and corresponding ES language feature polyfills.
Public base path configuration
If deploying under a nested public path, use the `base` config option or `vite build --base=/my/public/path/` command line flag. All asset paths will be automatically rewritten accordingly. JS-imported asset URLs, CSS url() references, and asset references in .html files are all automatically adjusted.
Dynamically concatenating URLs with BASE_URL
The globally injected `import.meta.env.BASE_URL` variable contains the public base path and can be used to dynamically concatenate URLs. This variable is statically replaced during build, so it must appear exactly as-is; `import.meta.env['BASE_URL']` will not work.
Production build output directory
By default, Vite builds the app for production to the dist folder.
Production build includes hash in filenames
In production builds, Vite includes hashes in the filenames and minifies the build output.