Implement SSR mode (server side rendering)

[gijsroge]

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

[LinusBorg]

This should probably be implemented as a plugin.

We also won't be able to use the mode flag because that's not what it's used for, it's used for definining which environment variables to load.

If you just have to deacivate the commonschunks plugins, you can do this in vue.config.js:

module.exports = {
  chainWebpack: config => {
    config.plugins
      .delete('split-vendor')
      .delete('split-vendor-async')
      .delete('split-manifest')
      .delete('inline-manifest')
  }
}

[gijsroge]

Yes, now that I think about it, it makes more sense as a plugin. Also thanks for the example, works great.

[yyx990803]

Regarding SSR as a plugin - it's low priority for us at the moment because Nuxt already does a great job.

[cj]

@yyx990803 @gijsroge I can make a plugin based on https://poi.js.org/plugins/vue-static.html and @egoist's amazing work.

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

[egoist]

@mydesireiscoma can you elaborate why you can't use Nuxt and how a vue-cli plugin would help you?🙂

I (and many other people too) don't like "Nuxt" / won't use it / can't use it for some reasons.

Is that a reason to make SSR a top prority for vue-cli 🤔

[lbjones]

This surprises me as well. The tagline on the front page is "no need to eject".

Since I need my whole site to be crawl-able for SEO purposes, it seems I need to eject and switch to Nuxt?

Am I understanding this correctly, or is there another way to achieve this?

[Akryum]

@lbjones It can be implemented as a third-party plugin or done manually without ejecting.

[lbjones]

Thank you @Akryum. I'll check them out.

[alidcast]

I could see why people wouldn't want to use Nuxt if all they need is a way to the bootstrap server only logic and don't need everything else it offers

i.e. If you're querying data with graphql, you don't really need to split components into /pages since everything already happens on a per-component basis

[Akryum]

https://github.com/Akryum/vue-cli-plugin-ssr

[dmikester1]

@Akryum So I added "ssr:serve": "vue-cli-service ssr:serve" to mypackage.json so I can do this using npm. Then I ran 'npm run ssr:serve'. I then received the following error:

(node:9500) UnhandledPromiseRejectionWarning: Error: ENOENT: no such file or directory, open 'C:\Users\user\Documents\git\vue-ssr-test\src\index.template.html '
at Object.fs.openSync (fs.js:646:18)
at Object.fs.readFileSync (fs.js:551:33)
at Promise (C:\Users\user\Documents\git\vue-ssr-test\node_modules@akryum\ vue-cli-plugin-ssr\lib\dev-server.js:49:17)

I don't find a index.template.html anywhere in my project, which it sounds like is the issue. Am I supposed to add it manually? What do I put in it? Or is there a command that I missed that will add it?

[RehanSaeed]

Could this issue be reopened? While Nuxt is very powerful, you shouldn't need to jump ship from the Vue CLI just for SSR. SSR can and has been implemented as a plugin (it's a work in progress though) and I think it should be a first party plugin owned by the vuejs organisation itself. People underestimate how much SSR is required for SEO and the like, you're often pointed to pre-rendering but that's just not feesible for any dynamic site of any real size.

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