Implement SSR mode (server side rendering)

What problem does this feature solve?

By default vue-cli-service uses commonChunksPlugin. But when using vue-server-renderer it expect one entry file. So commonChunksPlugin should be disabled.

Building for production...(node:77282) UnhandledPromiseRejectionWarning: Error: Server-side bundle should have one single entry file. Avoid using CommonsChunkPlugin in the server config.
    at Compiler.<anonymous> (/Users/gijs.roge/Sites/opcafegaannew/prototypes/premium-page/node_modules/vue-server-renderer/server-plugin.js:58:13)
    at next (/Users/gijs.roge/Sites/opcafegaannew/prototypes/premium-page/node_modules/@vue/cli-service/node_modules/tapable/lib/Tapable.js:204:14)
    at callback (/Users/gijs.roge/Sites/opcafegaannew/prototypes/premium-page/node_modules/copy-webpack-plugin/dist/index.js:77:17)
    at /Users/gijs.roge/Sites/opcafegaannew/prototypes/premium-page/node_modules/copy-webpack-plugin/dist/index.js:118:24
    at <anonymous>

What does the proposed API look like?

$ vue-cli-service build --mode server

Internally this should disable commonChunksPlugin and also set NODE_ENV to “server”.

[padcom]

In my personal opinion the SSR topic as such is just neglected by all frameworks (maybe besides Ember.js but that is a topic for another time). I think that having such a great tool as vue + vue cli it should be a no brainier that all the basic things (like splitting CSS into separate files and SSR to name just a few) should be available out of the box with no additional configuration required. There is already a ton of stuff that one needs to take into consideration when creation universal apps and the plumbing of build/server shouldn’t be one of them.

I very much like how the docs at ssr.vuejs.org start with a simple example and I think the entire thing should be as simple as the first example (https://ssr.vuejs.org/guide/#integrating-with-a-server).

With Vue CLI we have a pre-defined and extensible scaffolding and build system for Vue and yet we struggle with that one area that (apparently) is very much needed by a growing number of projects.

Nuxt.js isn’t the answer. It is a 3rd party that does things “their own way”. It requires a number of properties from a project (like router or separate state management) which are not always necessary to do SSR.

I strongly believe that if the core team would take the matter to heart there would be no match on the JavaScript framework landscape for Vue.js and that it would grow exponentially in popularity. I love the way things are progressing with Vue CLI, its modularity (that was for me the primary reason for switching from pure Webpack to POI back in the day) and how it speeds up the process of scaffolding new applications. It does its job very well and I am forever thankful to the authors for the fantastic job they are doing to make Vue and its ecosystem a reality.

[0x00000001A]

@yyx990803 Actually, I don’t like when VueJS team answers like that. I (and many other people too) don’t like “Nuxt” / won’t use it / can’t use it for some reasons.

Regarding <any official plugin here> as a plugin - it’s low priority because <nice another plugin> does a great job.