Kickoff: 3.0 plans

[yyx990803]

We have been discussing an upgrade for vue-cli for a while, in order to address a few issues in the current version.

Problems

1. Currently, project build configurations are directly included in the template. This leads to a few problems:

   • once created, it becomes difficult to upgrade an existing project to track latest changes in the remote template;

   • pulling directly from github lacks proper version control mechanism that npm packages have;

   • less experienced users can get intimidated by the seemingly complex code in the build directory.

2. Too many decisions to make upfront resulting in a less smooth onboarding experience.

   The user has to first pick a template, but for beginners they usually do not possess the experience to decide which template fits their use case best. The official webpack template has a number of questions regarding linters and test tools, which can also be intimidating for beginners.

Solutions

1. vue-cli@3.0 will be moving towards a "config/scripts in a package" model, which is commonly used among several other tools:

   • create-react-app
   • Next.js
   • Nuxt.js
   • Poi

2. Instead of forcing users to make non-reversible decisions upfront, we would:

   • Phase out browserify support. There will be just one template which is webpack based.

   • Configurations for common use cases (pwa, ts, ssr) can be added on demand via presets, similar to how Neutrino/Poi works. The presets can be maintained and versioned individually.

3. In addition to the encapsulated package, we will also offer the ability to configure the tooling via vue.config.js. This file exposes two functionalities:

   1. A centralized entry for configuring/toggling high-level built-in features, e.g. env variables, css extraction, API proxying.

   2. Get lower level access to the underlying webpack config and tweak it (probably with webpack-chain). This essentially works like a local preset.

Other Ideas

• We will probably split out vue build into an addon (e.g. vue-cli-build) so the initial install of vue-cli can be faster. vue build can simply try to call vue-cli-build, and prompt installation if it is not found.

• vue list will be deprecated, OR list available presets instead.

• Default integration of vue-test-utils and probably Jest as the runner (although it can lead to license concerns)

• Better error reporting, e.g. jumping directly to source code from error overlay.

• Grep for common warning / error messages and suggest potential doc links.

• Auto port detection (suggested by @billyryanwill)

• Your idea here

I realize this is in fact very similar to Poi and since @egoist has been an active contributor to vue-cli itself, I would love to get feedback from @egoist and potentially collaborate with him to build the new version. Maybe we can even build this on top of a fork of Poi?

/cc @vuejs/collaborators

[egoist]

This is what I imagine vue-cli might look like:

• vue create: Create a project with only app code (or name this command vue init)
• vue init: Still the old vue init behavior (or rename this command to vue clone)

The commands we set in package.json for projects generated by vue-cli:

• vue-scripts build: Build app for production use (webpack)
• vue-scripts dev: Run app with a dev server (webpack)
• vue-scripts test: Run Jest (?) against test files.

Basically a create-react-app + react-scripts structure but we don't eject, we make use of webpack-chain instead.

[yyx990803]

@egoist yep, exactly. Would you be interested in starting this? Feels like we can reuse/learn a lot from Poi. I currently have my hands full with 2.5, won't be able to work on this until that's released.

[Akryum]

Also, maybe we should make sure the whole flow is proxy-proof for enterprise usage.

[billyryanwill]

A really tiny thing from me (I love vue-cli already), would be automatic port hopping if the default port is already being used. A few of our less technical members have struggled setting up and aren't comfortable changing the port it runs on so it would be cool if this could be implemented!

If I'm being ignorant and this is already an option then please set me straight :)

[yyx990803]

@billyryanwill good point, that's definitely something people have been asking for.

[chrisvfritz]

@billyryanwill @yyx990803 The portfinder package makes this really easy! It's actually slated to be added to the Webpack template.

[dabernathy89]

Is a template for distributable components part of the roadmap?

[cristijora]

I personally enjoy POI a lot and it's presets. I think it's more controllable than create-react-app.
I also like the simplicity of next. Maybe combine and take the best pieces from all those 4 options?

[blocka]

the commands we set in package.json for projects generated by vue-cli:

vue-scripts build: Build app for production use (webpack)
vue-scripts dev: Run app with a dev server (webpack)
vue-scripts test: Run Jest (?) against test files.

We also need to deploy to a staging server as well, and the first thing we do on a vue-cli setup is remove the hardcoded NODE_ENV=production

I think there should be some thought in here as to how to allow this workflow out of the box.

[HerringtonDarkholme]

I would suggest an eject option similar to create-react-app. It's for advanced users and is a one-way operation. But I guess advanced users will want to have full control of their building scripts (compared to editing vue.config.js).

[egoist]

@HerringtonDarkholme with webpack-chain you actually get full control of your webpack config, and it's hard to have both eject and a preset system.

[karol-f]

Maybe Neutrino (https://neutrino.js.org/) by Mozilla is a good fit? It provides "presets" which can be easily customized and extended when needed.

Description - https://davidwalsh.name/neutrino
Custimization - https://neutrino.js.org/customization/

[egoist]

@yyx990803 : Better error reporting, e.g. jumping directly to source code from error overlay.

Maybe contribute to https://github.com/geowarin/friendly-errors-webpack-plugin (or a fork if necessary)

@karol-f : Maybe Neutrino (neutrino.js.org) by Mozilla is a good fit?

Sure, maybe start with making a Vue preset for Neutrino and wrap them all in a cli like vue-scripts or similar.

[HerringtonDarkholme]

@egoist I don't think eject can be replaced by webpack chain. For example, webpack chain doesn't generate other configuration file like .babelrc, .postcssrc, etc. Also, users have to write their own eject/export function.

it's hard to have both eject and a preset system.

Can you elaborate why it is hard? IMHO eject is one-way operation. that means, once ejected, the project is no longer influenced by preset. Upstream preset change don't need to be applied to ejected projects.