# Configuration Reference

# Global CLI Config

Some global configurations for @vue/cli , such as your preferred package manager and your locally saved presets, are stored in a JSON file named .vuerc in your home directory. You can edit this file directly with your editor of choice to change the saved options.

You can also use the vue config command to inspect or modify the global CLI config.

# Target Browsers

See the Browser Compatibility section in guide.

vue.config.js is an optional config file that will be automatically loaded by @vue/cli-service if it's present in your project root (next to package.json ). You can also use the vue field in package.json , but do note in that case you will be limited to JSON-compatible values only.

The file should export an object containing options:

module . exports = { }

Deprecated since Vue CLI 3.3, please use publicPath instead.

Type: string

Default: '/' The base URL your application bundle will be deployed at (known as baseUrl before Vue CLI 3.3). This is the equivalent of webpack's output.publicPath , but Vue CLI also needs this value for other purposes, so you should always use publicPath instead of modifying webpack output.publicPath . By default, Vue CLI assumes your app will be deployed at the root of a domain, e.g. https://www.my-app.com/ . If your app is deployed at a sub-path, you will need to specify that sub-path using this option. For example, if your app is deployed at https://www.foobar.com/my-app/ , set publicPath to '/my-app/' . The value can also be set to an empty string ( '' ) or a relative path ( ./ ) so that all assets are linked using relative paths. This allows the built bundle to be deployed under any public path, or used in a file system based environment like a Cordova hybrid app. Limitations of relative publicPath Relative publicPath has some limitations and should be avoided when: You are using HTML5 history.pushState routing; You are using the pages option to build a multi-paged app. This value is also respected during development. If you want your dev server to be served at root instead, you can use a conditional value: module . exports = { publicPath : process . env . NODE_ENV === 'production' ? '/production-sub-path/' : '/' }



Type: string

Default: 'dist' The directory where the production build files will be generated in when running vue-cli-service build . Note the target directory will be removed before building (this behavior can be disabled by passing --no-clean when building). TIP Always use outputDir instead of modifying webpack output.path .

Type: string

Default: '' A directory (relative to outputDir ) to nest generated static assets (js, css, img, fonts) under. TIP assetsDir is ignored when overwriting the filename or chunkFilename from the generated assets.

Type: string

Default: 'index.html' Specify the output path for the generated index.html (relative to outputDir ). Can also be an absolute path.

Type: boolean

Default: true By default, generated static assets contains hashes in their filenames for better caching control. However, this requires the index HTML to be auto-generated by Vue CLI. If you cannot make use of the index HTML generated by Vue CLI, you can disable filename hashing by setting this option to false .

Type: Object

Default: undefined Build the app in multi-page mode. Each "page" should have a corresponding JavaScript entry file. The value should be an object where the key is the name of the entry, and the value is either: An object that specifies its entry , template , filename , title and chunks (all optional except entry ). Any other properties added beside those will also be passed directly to html-webpack-plugin , allowing user to customize said plugin; Or a string specifying its entry . module . exports = { pages : { index : { entry : 'src/index/main.js' , template : 'public/index.html' , filename : 'index.html' , title : 'Index Page' , chunks : [ 'chunk-vendors' , 'chunk-common' , 'index' ] } , subpage : 'src/subpage/main.js' } } TIP When building in multi-page mode, the webpack config will contain different plugins (there will be multiple instances of html-webpack-plugin and preload-webpack-plugin ). Make sure to run vue inspect if you are trying to modify the options for those plugins.



Type: boolean | 'warning' | 'default' | 'error'

Default: 'default' Whether to perform lint-on-save during development using eslint-loader . This value is respected only when @vue/cli-plugin-eslint is installed. When set to true or 'warning' , eslint-loader will emit lint errors as warnings. By default, warnings are only logged to the terminal and does not fail the compilation, so this is a good default for development. To make lint errors show up in the browser overlay, you can use lintOnSave: 'default' . This will force eslint-loader to actually emit errors. this also means lint errors will now cause the compilation to fail. Setting it to 'error' will force eslint-loader to emit warnings as errors as well, which means warnings will also show up in the overlay. Alternatively, you can configure the overlay to display both warnings and errors: module . exports = { devServer : { overlay : { warnings : true , errors : true } } } When lintOnSave is a truthy value, eslint-loader will be applied in both development and production. If you want to disable eslint-loader during production build, you can use the following config: module . exports = { lintOnSave : process . env . NODE_ENV !== 'production' }

Type: boolean

Default: false Whether to use the build of Vue core that includes the runtime compiler. Setting it to true will allow you to use the template option in Vue components, but will incur around an extra 10kb payload for your app. See also: Runtime + Compiler vs. Runtime only .

Type: Array<string | RegExp>

Default: [] By default babel-loader ignores all files inside node_modules . If you want to explicitly transpile a dependency with Babel, you can list it in this option.

Jest config This option is not respected by the cli-unit-jest plugin, because in jest, we don't have to transpile code from /node_modules unless it uses non-standard features - Node >8.11 supports the latest ECMAScript features already. However, jest sometimes has to transform content from node_modules if that code uses ES6 import / export syntax. In that case, use the transformIgnorePatterns option in jest.config.js . See the plugin's README for more information.

Type: boolean

Default: true Setting this to false can speed up production builds if you don't need source maps for production.

Type: string

Default: undefined Configure the crossorigin attribute on <link rel="stylesheet"> and <script> tags in generated HTML. Note that this only affects tags injected by html-webpack-plugin - tags directly added in the source template ( public/index.html ) are not affected. See also: CORS settings attributes

Type: boolean

Default: false Set to true to enable Subresource Integrity (SRI) on <link rel="stylesheet"> and <script> tags in generated HTML. If you are hosting your built files on a CDN, it is a good idea to enable this for additional security. Note that this only affects tags injected by html-webpack-plugin - tags directly added in the source template ( public/index.html ) are not affected. Also, when SRI is enabled, preload resource hints are disabled due to a bug in Chrome which causes the resources to be downloaded twice.

Type: Object | Function If the value is an Object, it will be merged into the final config using webpack-merge . If the value is a function, it will receive the resolved config as the argument. The function can either mutate the config and return nothing, OR return a cloned or merged version of the config. See also: Working with Webpack > Simple Configuration

Type: Function A function that will receive an instance of ChainableConfig powered by webpack-chain . Allows for more fine-grained modification of the internal webpack config. See also: Working with Webpack > Chaining

Deprecated since v4, please use css.requireModuleExtension instead.

In v3 this means the opposite of css.requireModuleExtension .

Type: boolean

Default: true By default, only files that ends in *.module.[ext] are treated as CSS modules. Setting this to false will allow you to drop .module in the filenames and treat all *.(css|scss|sass|less|styl(us)?) files as CSS modules. TIP If you have customized CSS Modules configurations in css.loaderOptions.css , then the css.requireModuleExtension field must be explicitly configured to true or false , otherwise we can't be sure whether you want to apply these options to all CSS files or not. See also: Working with CSS > CSS Modules

Type: boolean | Object

Default: true in production, false in development Whether to extract CSS in your components into a standalone CSS files (instead of inlined in JavaScript and injected dynamically). This is always disabled when building as web components (styles are inlined and injected into shadowRoot). When building as a library, you can also set this to false to avoid your users having to import the CSS themselves. Extracting CSS is disabled by default in development mode since it is incompatible with CSS hot reloading. However, you can still enforce extraction in all cases by explicitly setting the value to true . Instead of a true , you can also pass an object of options for the mini-css-extract-plugin if you want to further configure what this plugin does exactly.

Type: boolean

Default: false Whether to enable source maps for CSS. Setting this to true may affect build performance.

Type: Object

Default: {} Pass options to CSS-related loaders. For example: module . exports = { css : { loaderOptions : { css : { } , postcss : { } } } } Supported loaders are: css-loader postcss-loader sass-loader less-loader stylus-loader It's also possible to target scss syntax separately from sass , with the scss option. See also: Passing Options to Pre-Processor Loaders TIP This is preferred over manually tapping into specific loaders using chainWebpack , because these options need to be applied in multiple locations where the corresponding loader is used.



Type: Object All options for webpack-dev-server are supported. Note that: Some values like host , port and https may be overwritten by command line flags. Some values like publicPath and historyApiFallback should not be modified as they need to be synchronized with publicPath for the dev server to function properly.



Type: string | Object If your frontend app and the backend API server are not running on the same host, you will need to proxy API requests to the API server during development. This is configurable via the devServer.proxy option in vue.config.js . devServer.proxy can be a string pointing to the development API server: module . exports = { devServer : { proxy : 'http://localhost:4000' } } This will tell the dev server to proxy any unknown requests (requests that did not match a static file) to http://localhost:4000 . WARNING When devServer.proxy is set to a string, only XHR requests will be proxied. If you want to test an API URL, don't open it in the browser, use an API tool like Postman instead. If you want to have more control over the proxy behavior, you can also use an object with path: options pairs. Consult http-proxy-middleware for full options: module . exports = { devServer : { proxy : { '^/api' : { target : '<url>' , ws : true , changeOrigin : true } , '^/foo' : { target : '<other_url>' } } } }

Type: boolean | number

Default: require('os').cpus().length > 1 Whether to use thread-loader for Babel or TypeScript transpilation. This is enabled for production builds when the system has more than 1 CPU cores. Passing a number will define the amount of workers used.

WARNING Do not use parallel in combination with non-serializable loader options, such as regexes, dates and functions. These options would not be passed correctly to the respective loaders which may lead to unexpected errors.

Type: Object Pass options to the PWA Plugin .

Type: Object This is an object that doesn't go through any schema validation, so it can be used to pass arbitrary options to 3rd party plugins. For example: module . exports = { pluginOptions : { foo : { } } }

Babel can be configured via babel.config.js .

TIP Vue CLI uses babel.config.js which is a new config format in Babel 7. Unlike .babelrc or the babel field in package.json , this config file does not use a file-location based resolution, and is applied consistently to any file under project root, including dependencies inside node_modules . It is recommended to always use babel.config.js instead of other formats in Vue CLI projects.

All Vue CLI apps use @vue/babel-preset-app , which includes babel-preset-env , JSX support and optimized configuration for minimal bundle size overhead. See its docs for details and preset options.

Also see the Polyfills section in guide.

ESLint can be configured via .eslintrc or eslintConfig field in package.json .

See @vue/cli-plugin-eslint for more details.

TypeScript can be configured via tsconfig.json .

See @vue/cli-plugin-typescript for more details.

# Unit Testing

See @vue/cli-plugin-unit-jest for more details.

See @vue/cli-plugin-unit-mocha for more details.

# E2E Testing

See @vue/cli-plugin-e2e-cypress for more details.

See @vue/cli-plugin-e2e-nightwatch for more details.

See @vue/cli-plugin-e2e-webdriverio for more details.