Eject from Vue CLI / Export Webpack Config

[dylanized]

What problem does this feature solve?

For advanced projects, a developer might want to customize the Webpack config directly.

This would allow for more granular optimization of build times and serving times, and permit a developer to configure Webpack using their previous Webpack knowledge, instead of being forced to learn the "Vue way". This would align with Vue's goal of being a progressive framework that can be used in different ways.

What does the proposed API look like?

a vue eject or vue export command would generate a Webpack config file. Then the developer could manually delete the Vue config file, and change their tasks to not rely on vue-cli-service.

[Akryum]

You can already use the builtin webpack-merge and webpack-chain tools to change everything in the webpack configuration without having to eject. So there is no benefit of doing so and only downsides.

[dylanized]

I think being able to optimize the build/serve dependencies and speed, at a fine grain level, is a big benefit. I also think there's a project management benefit to knowing that when you spin up a project with Vue CLI, you're not locked into it forever. This makes the decision less risky for organizations that are hesitant on using new tools. (Yes a user take an existing Vue CLI app and retrofit a new Webpack config from scratch, but that is clunky and time consuming).

[sirlancelot]

I would use chainWebpack or configureWebpack for customizing the build. You are given near-complete control over Webpack through these two options. Extracting the internal state of the config can be done easily using either vue inspect or dropping a debugger statement inside your custom configureWebpack function. "Ejecting" is unnecessary and will only create maintenance problems.

[LinusBorg]

I think being able to optimize the build/serve dependencies and speed,

In terms of optimization, I don't see a single thing you could do to an ejected webpack config that you couldn't do with the vue.config.js API. And the construction of this config when running the actual command can't be noticably slower than a slim one on any non-ancient hardware.

The only one little advantage that I can see is that you may be able to get rid of some dependencies during npm install, which with vue-cli-service you will have to install even though you later remove them from the created config.

I also think there's a project management benefit to knowing that when you spin up a project with Vue CLI, you're not locked into it forever.

You're only "locked in" if you define that as "there's no way to eject without me putting some work in".

Ejecting the whole config for all the different ways you might be using it (build with its various flags, different adjustments to configs that are applied when using the unit-jest vs. the unit-mocha plugins etc.) would be pretty hard and clunky.

Yes a user take an existing Vue CLI app and retrofit a new Webpack config from scratch, but that is clunky and time consuming

...but it's actually doable. And for someone who feels limited by the possibilities that our API provides, it should be doable with a bit of work.

So I think we should consider a guide on how to approach this in a reasonable way, but a way of ejecting that actually results in a config that works seamlessly with e.g. webpack-dev-server, a normal build command and a call of /node_modules/.bin/jest isn't really feasable in my opinion.

[suau]

I can see benefits of having a eject feature.
While configs merges work, it's a lot easier to predict what the final config looks like if the config is actually present, especially for those who are not very familiar with webpack.
There will always be use cases that aren't covered by vue-cli (yet) and for these cases there should be an easy escape hatch.

Just as an example I was looking for adding SSR to the build and found two examples:

1. https://github.com/eddyerburgh/vue-cli-ssr-example
   Uses a environment variable to switch between two different overrides for the client/server. Works, but why would I do that if webpack is perfectly capable of handling different build targets.
2. https://www.npmjs.com/package/@akryum/vue-cli-plugin-ssr
   A WIP plugin with support for things I'm not using, not sure what it does under the hood or if it works together with other plugins.

Meanwhile there is a nice step by step guide in the vue docs using webpack, no additional plugins/hacks necessary.

[LinusBorg]

An eject feature won't happen in the foreseeable future, as it would be quite complicated to do with the current architecture.

I do agree that our cutomization API, while technically allowing to customize everyting is not 100% as straightforward to use as a webpack config that you have right in front of you.

However that's a tradeoff we are willing to accept.

[amoshydra]

Recently I needed a way to customise webpack in way that vue-cli does not allow.

For example, changing the entry field of the webpack.config in order to achieve this: #1065 (comment). As of now, vue-cli will always override some of the configuration regardless of what the developer set in vue.config.js e.g.

vue-cli/packages/@vue/cli-service/lib/commands/build/resolveLibConfig.js

Lines 92 to 94 in 1e200c5

	rawConfig.entry = {
	[entryName]: realEntry
	}

However, at the same time, vue-service-cli provide a way for us to read in a base webpack.config.js here
https://github.com/vuejs/vue-cli/blob/dc2f8e8/packages/%40vue/cli-service/webpack.config.js

This seems to be quite useful if we need perform any manual configuration to the webpack.config.js. My current setup look like this.

/projectRoot/webpack.config.js

const merge = require('webpack-merge');
const path = require('path');
const util = require('util');
const originalWebpackConfig = require('@vue/cli-service/webpack.config');
const vueConfigWebpackConfig = require('./vue.config').configureWebpack || {};

const isDevEnvironment = (process.env.NODE_ENV === 'development' || process.env.NODE_ENV === 'test');
const fromRoot = (filepath = '') => path.resolve(__dirname, filepath);

// Merge and configure configs
const outputConfig = merge(
  originalWebpackConfig,
  {

Since we will now have our own webpack.config.js, we don't need to rely on vue-cli-service for building/development anymore if you want to.

yarn webpack

Challenge

I can no longer use webpack-chain to configure the webpack. Thus it become quite tedious to configure a plugin (e.g. vue-loader)

[gemmi]

My project is controlled by another VSCODE plugin based on webpack.config.js, this plugin helps me to login and bundle/zip/upload files to server and fails to work without the config file, so if i can't export it,is there a way to fix this problem up with cli3?

[jkzing]

@gemmi, Yes, see https://cli.vuejs.org/guide/webpack.html#using-resolved-config-as-a-file

[haoqunjiang]

The above discussion has made the point quite clear.
We won't consider adding this feature in the forseeable future. So I'm closing this issue now.

[shirshak55]

@sodatea For me vue cli has served its purpose and i no longer need it how can i get like single webpack.config.js so that i can use it with laravel. Using vue cli is always hackier to work with backend like laravel.

I don't want bloat like vue cli uses i want to get clean will it be possible?