Shared Options | Vite

Dep Optimization Options
Unless noted, the options in this section are applied to all dev, build, and preview.
Project root directory (where index.html is located). Can be an absolute path, or a path relative to the current working directory.
See Project Root for more details.
Base public path when served in development or production. Valid values include:
See Public Base Path for more details.
Specifying this in config will override the default mode for both serve and build. This value can also be overridden via the command line --mode option.
See Env Variables and Modes for more details.
Entry points of your application, resolved relative to the project root. This works as the default value for build.rolldownOptions.input, build.lib.entry, build.ssr (if true), and optimizeDeps.entries when those are not set explicitly.
This is useful when your application does not use an index.html entry, so you only need to declare the entry once instead of repeating it across the options above.
Define global constant replacements. Entries will be defined as globals during dev and statically replaced during build.
Vite uses Oxc's define feature to perform replacements, so value expressions must be a string that contains a JSON-serializable value (null, boolean, number, string, array, or object) or a single identifier. For non-string values, Vite will automatically convert it to a string with JSON.stringify.
For TypeScript users, make sure to add the type declarations in the vite-env.d.ts file to get type checks and Intellisense.
Array of plugins to use. Falsy plugins are ignored and arrays of plugins are flattened. If a promise is returned, it would be resolved before running. See Plugin API for more details on Vite plugins.
Directory to serve as plain static assets. Files in this directory are served at / during dev and copied to the root of outDir during build, and are always served or copied as-is without transform. The value can be either an absolute file system path or a path relative to project root.
Defining publicDir as false disables this feature.
See The public Directory for more details.
Directory to save cache files. Files in this directory are pre-bundled deps or some other cache files generated by vite, which can improve the performance. You can use --force flag or manually delete the directory to regenerate the cache files. The value can be either an absolute file system path or a path relative to project root. Default to .vite when no package.json is detected.
Defines aliases used to replace values in import or require statements. This works similar to @rollup/plugin-alias.
The order of the entries is important, in that the first defined rules are applied first.
When aliasing to file system paths, always use absolute paths. Relative alias values will be used as-is and will not be resolved into file system paths.
More advanced custom resolution can be achieved through plugins.
If you have configured aliases for SSR externalized dependencies, you may want to alias the actual node_modules packages. Both Yarn and pnpm support aliasing via the npm: prefix.
The Object format allows specifying aliases as a key, and the corresponding value as the actual import value. For example:
The Array format allows specifying aliases as objects, which can be useful for complex key/value pairs.
When find is a regular expression, the replacement can use replacement patterns, such as $1. For example, to remove extensions with another, a pattern like the following might be used:
If you have duplicated copies of the same dependency in your app (likely due to hoisting or linked packages in monorepos), use this option to force Vite to always resolve listed dependencies to the same copy (from project root).
For SSR builds, deduplication does not work for ESM build outputs configured from build.rolldownOptions.output. A workaround is to use CJS build outputs until ESM has better plugin support for module loading.
Additional allowed conditions when resolving Conditional Exports from a package.
A package with conditional exports may have the following exports field in its package.json:
Here, import and require are "conditions". Conditions can be nested and should be specified from most specific to least specific.
development|production is a special value that is replaced with production or development depending on the value of process.env.NODE_ENV. It is replaced with production when process.env.NODE_ENV === 'production' and development otherwise.
Note that import, require, default conditions are always applied if the requirements are met.
In addition, the style condition is applied when resolving style imports, e.g. @import 'my-library'. For some CSS pre-processors, their corresponding conditions are also applied, i.e. sass for Sass and less for Less.
List of fields in package.json to try when resolving a package's entry point. Note this takes lower precedence than conditional exports resolved from the exports field: if an entry point is successfully resolved from exports, the main field will be ignored.
List of file extensions to try for imports that omit extensions. Note it is NOT recommended to omit extensions for custom import types (e.g. .vue) since it can interfere with IDE and type support.
Enabling this setting causes vite to determine file identity by the original file path (i.e. the path without following symlinks) instead of the real file path (i.e. the path after following symlinks).
Enables the tsconfig paths resolution feature. paths option in tsconfig.json will be used to resolve imports. See Features for more details.
paths only applies to a file matched by a tsconfig.json through its files or include. Non-JS extension files should be explicitly listed in them, since a bare "src" or "**/*" include only matches TS/JS extensions, aligning with TypeScript's behavior. For example, to use a paths alias inside a CSS file (such as @import '@/foo.css'), list those files in files, or add an explicit extensio