Vue-cli: DLL mode bundle sizes

[alexdilley]

Version

3.0.0-beta.6

Reproduction link

https://codesandbox.io/s/ppo0y403lj

Steps to reproduce

Enable DLL mode by setting the dll option in vue.config.js to true (as per docs):

// vue.config.js
module.exports = {
  dll: true
}

What is expected?

Vendor libs not to be included in app bundle; bundle sizes to be reduced.

What is actually happening?

With the option set to true, some node_modules are packaged into the app bundle – the opposite of a build with the option disabled, and hence the opposite of the option's function described by the documentation.

Comparison of build sizes given the following base project set-up:

vue create -i '{"plugins": { "@vue/cli-plugin-babel": {} }, "router": true, "vuex": true}' my-project

dll: false (the default):

  File                          Size                   Gzipped

  dist/js/vendor.456df753.js    95.01 kb               32.36 kb
  dist/js/app.be870e84.js       12.51 kb               8.05 kb
  dist/css/app.8b290d57.css     0.42 kb                0.26 kb

  Images and other types of assets omitted.

dll: true:

  File                          Size                   Gzipped

  dist/js/vendor.3884c493.js    95.12 kb               32.29 kb
  dist/js/app.d8cf8ae4.js       13.89 kb               8.71 kb
  dist/css/app.8b290d57.css     0.42 kb                0.26 kb

  Images and other types of assets omitted.

The difference is exacerbated as projects grow.

---

Is this condition the opposite of what it should be?

Unless I'm mistaken in how this feature should work, the consequence of changing/fixing this will be that all vue-cli generated apps' bundle sizes will subsequently increase, except those where the option has already been set to true in the anticipation it would reduce bundle sizes (which it isn't currently), in which case future builds _will_ be smaller :)

[LinusBorg]

codesandbox does not use vue-cli 3 yet, so adding a vue.config.js file wo't have any effect, so this is not a reproduction we can work with. I assume you created it to have a link to share?

Anyway, I created a project from the command you specified, added webpack-bundle-analyzer to the config and ran with and without the dll option.

Result: There are no libs from vendor.js added into app.js. the slight increase in size is most probably due do boilerplate necessary to link map dependencies to the modules exported by the vendor bundle. This boilerplate would usually be extracted into a manifest file, which happens differently than with a normal code split.

It should probably be noted in the docs that DLL bundling is not meant for production anyway - it's a performance optimization during development, mostly. At least that's how I think about it.

[alexdilley]

A baseline/empty project probably wasn't the best example as the difference is tiny and the node_modules fragment a slither in the webpack-bundle-analyzer output. And, yes, I should have simply said that a reproduction link was "not applicable". Apologies for misleading.

Using the chrisvfritz/vue-enterprise-boilerplate project (which uses vue-cli 3) as a meatier example, I get these results:

dll: true:

  File                          Size                   Gzipped

  dist/js/vendor.f42dc035.js    194.47 kb              66.21 kb
  dist/js/app.e9fb5e4e.js       72.88 kb               27.47 kb
  dist/css/app.6c1ddbc9.css     50.91 kb               13.43 kb

  Images and other types of assets omitted.

(I don't know why webpack-bundle-analyzer isn't visualising the vendor bundle here.) Note, the node_modules in the app bundle. This seems contrary the what the docs describe:

DLL mode builds your dependencies into a separate vendor bundle.

dll: false:

  File                          Size                   Gzipped

  dist/js/vendor.07b932ed.js    130.71 kb              44.58 kb
  dist/js/app.8be4020c.js       64.07 kb               23.66 kb
  dist/css/app.6c1ddbc9.css     50.91 kb               13.43 kb

  Images and other types of assets omitted.

Which _is_ separating all vendor dependencies out of the app bundle (i.e. what the docs say dll: true should achieve).

In relative terms the difference in bundle sizes is notable.

Your comment regarding DLL being a build perf optimisation and not intended for production suggests I have maybe misinterpreted the docs (or that they're contradictory). It is perhaps to be expected that DLL mode produces larger build sizes and a less clear separation in bundle sizes in the name of faster build times _in dev_. But given the variance in bundle size, it's fairly imperative to disable this mode for production builds...?

A production build _should_ split vendor assets from your more changeable application bundle (right?). You get that even if you don't enable DLL mode, though. I therefore don't think DLL is about that and that's perhaps what's misleading in the documentation.

[chrisvfritz]

I definitely misunderstood this as well. 😅 I agree that production mode should disable this. The way it currently reads, it also sounds like it's partly a build size optimization that _enables_ vendor bundle splitting:

DLL mode builds your dependencies into a separate vendor bundle which will be reused on future builds as long as your dependencies did not change.

After making the behavior change, I'm thinking we may want to reword that to be:

DLL mode caches your dependencies in development so they don't have to be re-evaluated between builds.

@LinusBorg What do you think?

[LinusBorg]

That sounds much better

[yyx990803]

So, DLL mode is in fact meant for production builds. It is only for projects that are so big that builds can take minutes.

The reason for DLL builds having a bigger size is probably because DLL vendor bundle includes all dependencies listed in package.json without tree-shaking. So, this is a tradeoff that the user has to make on their own - sacrificing bundle size for a faster build, or the other way around. This may also has something to do with auto-dll-webpack-plugin, which is used in producing the DLL bundle.

I think we should probably mark DLL mode as experimental for now.

[Akryum]

I have a bunch of code I use at work: https://gist.github.com/Akryum/53da1c59775cdb4beace2f6189b40205 Maybe it can be useful.

[alexdilley]

Interesting point about DLL mode including all and sundry – that explains the increase in build size. I'm still sceptical as to whether anyone would intentionally make this trade-off with production builds – the part regarding splitting a bundle to extract vendor libs, yes...but you get that with cli-service regardless 🌟

I think we should probably mark DLL mode as experimental for now.

That sounds sensible. #1002 could therefore be closed, or serve as a placeholder PR for marking it experimental.

Confusion reigns (sorry!)!

[yyx990803]

Closing as we are planning to upgrade to webpack 4, and due to the perf improvements in webpack 4, we will remove built-in DLL support as it's providing less value and no longer worth the extra complexity/maintenance cost.