Vue-cli: Kickoff: 3.0 plans

Created on 12 Sep 2017  ·  80Comments  ·  Source: vuejs/vue-cli

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. [email protected] will be moving towards a "config/scripts in a package" model, which is commonly used among several other tools:

  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

discussion

Most helpful comment

@brianvoe That animation ✨

All 80 comments

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.

@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.

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

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 :)

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

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

Is a template for distributable components part of the roadmap?

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?

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.

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).

@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.

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/

@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.

@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.

Well, you don't need to eject to use a .babelrc or .postcsssrc file.

Is it also possible to add development build command in package.json like

vue-scripts build-dev: Build app for development use (webpack)

this is specially useful if you want to test and debug on remote server.

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

How much effort do you believe this would take? Assuming I know very little about the subject but would be willing to learn :)

Maybe presets or something to optionally add tools like CSS lint, eslint, storybook, visual testing etc.

Vuex is so commonly used, it would be good to add a Vuex option.
This would also help enforce that advanced configurations (i.e. pwa & whatever else comes along) mesh well with vuex.

Any thoughts on renaming it to create-vue-app to take advantage of Yarn’s create functionality and to standardize with the rest of the ecosystem?

@elpete FYI, there's already create-vue-app

Will multi entries be supported in one project?

This sounds exactly like the process i built. :smile:
Docs need some update but we use this for our production apps. The general purpose is you dont need any configuration unless you want to add additional webpack plugins or adjustments aside from the base webpack config.
http://vue-build.com

@brianvoe That animation ✨

@posva Thanks!

To further @LinusBorg's mention in #935, it would be awesome if vue-cli 3's 'main'/default template supported native implementations of ES2015+ (via <script type="modules"> with fallback transpilation) as it appears we're nearing the age where it makes sense to serve these directly[1].

[1] https://philipwalton.com/articles/deploying-es2015-code-in-production-today/

@mismith I'm not sure it makes sense right now. My understanding is <script type="modules"> currently offers zero benefits, and in the near future, the best we can hope for is they might not be _as dramatically_ worse than a compiled build with Webpack.

@chrisvfritz Fascinating. I guess I may have jumped the gun here :P

@chrisvfritz What @mismith means (see the article he linked) is not so much a true module support as it uses a <script type="module> tag to serve an ES6 bundle, and a <script nomodule> tag to serve an ES5 bundle.

The content of the ES6 bundle is still a "normal" webpack bundle, but not transpiled to ES6.

So you essentially build two versions of your bundle, and new browsers pick up the ES6 bundle while older ones, not supporting type="module", will fall back on the second one.

That should be achievable.

Chiming in with two minor points from a person that uses vue-cli webpack template and someone that was involved in Yeoman (boilerplate generators) back in the day.

  1. There is a balance between easy to use configuration and obfuscating the projects a user is installing. It was very easy to get started on a Vue app with the vue-cli webpack template, but took me a couple days of unravelling configuration files before I was able to understand the webpack files and alter them significantly. A balance is good; just pointing out if you use vue-cli's template to learn webpack the distance between config and use, and reuse of config in multiple environments, can make it difficult to understand. I've gotten a lot of benefit from projects that are lighter on config and guide you to learning the underlying technology.

  2. When I was involved in the Yeoman community there was a lot of desire to build generators that could be updated upstream and then backport functionality into an already scaffolded project. IIRC after a year+ of effort it was abandoned. I saw a lot of effort not pay off. People changed the code significantly as soon as the project was templated, which made updating very difficult.

Not saying that these things are impossible or bad, just pointing out some cautionary experiences I've had with them. Love the work you're doing, and thanks!

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

Not really sure we're talking about the same thing, but the workflow we (somewhat amateur frontend programmers) are trying to configure for our fullstack people is like this:

  • npm run dev-remote should run a local development server (localhost:3000, or whatever) that proxies anything it does not know about to a preconfigured remote server (server:80, server:443)
  • npm run dev-local should run a local development server that proxies anything it does not know about to a local server (e.g. running in a Java IDE)

Most proxy solutions will specifically proxy by url, e.g. "/api" or the like. We'd really like to proxy "anything not found", because, well, legacy urls ("/user.json", "/something/else.json"). Also, there are few examples that let you easily switch the address of the backend server without configuration.

@elygre that will be a hard thing to because it would require to somehow make the devserver aware of the routes that vue-router knows. I don't think it's possible to do with webpack-dev-server at least, we would have to write our own solution for that.

@LinusBorg Most of my work is on java, but would it not be possible to "attach" the proxy to a 404-handler of some sort?

The use case is to create an app that has a public path of e.g./onboarding, which I want to deploy to a server that has all sorts of apis: /users, /security, /andmore. The devserver would then be doing something like this:

  • First hand it to the vue-app, for handling
  • If 404 not found, proxy to server (for any other path)

I can say for sure that "someone" is creating 404's if I attempt to access the missing /asdf endpoint using the devserver -- though I am not sure whether it is possible to replace that with a proxy.

As i can understand Chrome can import and debug es6 modules now. Does vue team plan to do new template without webpack (minimal webpack for .vue, sass etc)?
https://developers.google.com/web/updates/2017/07/devtools-release-notes#modules

Hello everyone! First of all amazing work and thank you for your efforts! I have only one question: any idea on how long the development of vue-cli 3.0 will take?

Since we lost our 8ball, it's very hard to say :)

But to be serious: We are not even sure of the complete feature set, not is it clear which members will work on this - it's next to impossible to give you a halfway reliable number.

But it will be less than 6 months :-P

@LinusBorg Evan and Egoist would be leading the project.

Roadmap: https://github.com/vuejs/roadmap

I'm aware of this, I was referring to the fact that there's no real plan (yet) how these two (and possible contributors) will work on this, in what cycle / priority, starting when, etc. Poorly worded on my part.

Would like to give you my rollup new experience, maybe you are interested in an rollup template?

Not sure if this is already possible, but i'd like the ability to inject the vue init options into an existing project. For example if I decline to include vue-router at first, but later change my mind, i'd want vue-cli to add the necessary wepack config/files to my project. Same for the eslint, and testing options.

Not speaking for the Vue team, but in my experience this is very hard
because users edit their application, move files, add lines, etc.

Might be possible with something like create react app, pre-ejection, where
you can guarantee file location and contents.

@robwierzbowski And that's basically what's stated in the main post. So if "shit gets done", in the future we'll be able to simply scaffold a new project and "copy-paste" the src folder (and some custom config we wrote).

@Frondor Thanks, for some reason I thought that was still under discussion. Should have reviewed before I posted!

I wish @3.0 can make more useful cli command like run dev ,run test e.g.

It's very interesting to read through this issue and learn about the awesome momentum it has. I have been getting ready to tear the vue-webpack template apart so I can structure things my way and also add support for Workbox, it looks like all the Vue PWA templates out there still do not use it?

When is the new CLI expected to be ready to use? Is using POI or SAO or Vue-Build a better option?

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

The license shouldn't be an issue anymore: https://code.facebook.com/posts/300798627056246/relicensing-react-jest-flow-and-immutable-js/

Update: now WIP in the next branch. Still early stages, but the architecture is in place. Everything is subject to change and it's mostly a preview for template maintainers.

Could these vue-cli scripts be invoked using the vue command itself?

Something like npm's scripts: vue run test, vue run dev? Currently this is done through vue-cli-service vue-cli-service test, vue-cli-service dev. Not really a big deal, since these will be most likely used through npm scripts, just an idea.

@rigor789 what's the point on that if you are already running npm? What's the advantage of executing those scripts from this cli instead of package.json file?

@Frondor there is no advantage really, and like i mentioned it's not a big deal just simply an idea!

I can't think of a situation where one might run these commands directly though, so unless that change is a matter of a couple extra lines of code at most, it's not even worth working on...

I think that a deploy script should be included like vue-scripts deploy, maybe with multiple targets, like the following:

vue-scripts deploy:staging
vue-scripts deploy:gh-pages
vue-scripts deploy:producion

Or:

vue-scripts deploy staging
vue-scripts deploy gh-pages
vue-scripts deploy producion

I've noticed a few people having issues deploying, especially in certain use cases such as GitHub project pages, etc.

If there was an option to setup a default deploy target and branch during installation of a project, that would be cool. Maybe as a preset?

I have the functionality working at the moment with a Vue CLI 2.5 PR and it saves so much time not having to install a deployment strategy in each project.

Would it be useful to have a '.vue-cli' folder in the users home directory for storing things such as prompt modules, features, config.js, answers.js and anything else that way need to go in there?

So far we only have one config file that needs to be saved in the user's project folder. Or have I missed something?

I maintain a custom template, and it's not possible to add additional dependencies.

This template use metalsmith plugins that are available on NPM, but I have to push them in the template repository in a lib directory for vue-cli to be able to use them while generating project.

Would it be possible to support custom template dependencies for next version ?

That will be possible through presets, yes

If we say created a project with vue-cli webpack template for example and you've updated the template to include fixes, new features/configuration etc, will there be a way to update it to the latest version in place? Like react you can update the react-scripts dependency in your project - it would be good to have something similar to this.

Something like: vue update webpack <foldername>

No, The "ole" templates will not get an update mechanism.

But new projects created with the new cli will.

Sounds spot on. V3 onwards I gather?

Since v3 is made from scratch with a complete new architecture, it's safe to say that it will not be retro-compatible.

also i think on vue-cli or webpack template static path on build prod should be fixed... all the assets are currently build as src=static/js/..... which on windows os or xampp apache is undefined path unless i change all to ./static/js/ ....

root path : http://localhost/prodbuild/

static path on npm run build : static/[js/css]/....

in which the browser is assuming the assets are on http://localhost/static/[js/css/]/... instead of http://localhost/prodbuild/static/[js/css]/...

thanks

This is not a thing to be discussed here, the webpack template has its own repository.

I have to say I was really curious to try out v3 as I have been using my own custom templates with v2. However the requirement of yarn rather than something like lerna which is compatible with npm as well is a huge non starter for me.

@LinusBorg What I meant by multiple configs is, come devs or designers may want to have, for example, the choice to save different presets, rather than one default configuration.

@codetheorist 3.x allows you to save multiple presets.

How do we pass options to the webpackConfig object? I would like to modify some options which are passed in cli-service/lib/config/prod.js but I wasn't able to figure out how to do this.

@ralrom docs are not ready yet, but here's how:

Create a vue.config.js in root (you may need to remove/copy the "vue" field in package.json first):

// vue.config.js
module.exports = {
  chainWebpack: chainableConfig => {
     // modify config with webpack-chain
     // https://github.com/mozilla-neutrino/webpack-chain
  },

  configureWebpack: config => {
    // mutate config directly, or return new config
  },

  // object literal will be merged into base config using webpack-merge
  configureWebpack: {
    // ...
  }
}

(you may need to remove/copy the "vue" field in package.json first)

@yyx990803 Where should it be copied?

The simple presence of vue.config.js disables the linter, so I try to add the functionality back.

But when added to configureWebpack I get Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema..
When added directly in the export, nothing happens.

Is there any other side effect when using vue.config.js?

@Ldoppea

module.exports = {
  lintOnSave: true,
  configureWebpack: ...
}

It works, thanks 😉

How do you enable source maps to those loaders on the 3.0 CLI?

How can I make it as a multi-page application?
Will it match the same name files?
for example:

src/index.vue to public/index.html
src/user.vue to public/user.html

Or I only can achieve this by setting webpack in vue.config.js?
thank you.

Closing this as we are close to the first beta of 3.0 - if you have any particular feedback regarding current alpha, please submit issues with specific details. Thanks everyone for participating in the discussion.

你好! 我有时候会用hbuilder直接打包成安卓的app,在vue cli 2.0中只要将的config下的index.js的改成assetsPublicPath: './',路径就完全正确.在3.0中我需要自己将dist里的html引用加点 就像这样
link rel=preload as=script href=./js/vendor.6c050399.js

能不能加个webapp模式 ???

why yarn build when i am using npm ? very confusing and where did the webpack config go on vue-cli 3?

the whole point is that you don't _have_ to worry about the webpack config.
It's abstracted away behind one easily upgradable depedency

On Wed, Feb 21, 2018 at 5:43 AM, Serak Shiferaw notifications@github.com
wrote:

why yarn build when i am using npm ? very confusing and where did the
webpack config go on vue-cli 3?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-cli/issues/589#issuecomment-367285619, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACoukZI3zaenIljNMVx9b9RMxr4rUfqks5tW_NlgaJpZM4PU2yY
.

what happens when there is a bug in default config file. i use to change some value in config/index.js so than when i build for production every link works as it should be

```
build: {
// Template for index.html
index: path.resolve(__dirname, '../dist/index.html'),

// Paths
assetsRoot: path.resolve(__dirname, '../dist'),
assetsSubDirectory: 'static',
assetsPublicPath: '',  // use to be assetsPublicPath: '/' in which it assumes my page is in the root directory like localhost/vendor.js instead of localhost/whateverfolder/vendor.js

```

@serak take a look at the configuration docs: https://github.com/vuejs/vue-cli/blob/dev/docs/config.md more specifically the baseUrl option

@serak read the documentation please. Locking this thread.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JIANGYUJING1995 picture JIANGYUJING1995  ·  3Comments

b-zee picture b-zee  ·  3Comments

csakis picture csakis  ·  3Comments

Akryum picture Akryum  ·  3Comments

brandon93s picture brandon93s  ·  3Comments