Webpack: Consider using DllPlugin and DllReferencePlugin over CommonsChunkPlugin?

[myst729]

Currently the template is using CommonsChunkPlugin for bundling shared vendor libs. This saves a lot of bytes. However, the process is executed every time the production build runs, although output with the same hash.

In my personal use case, I use DllPlugin and DllReferencePlugin to run a pre-build for vendor libs. This way, The build only needs to bundle my app if no extra dependencies were installed since last pre-build. This speeds up the build process significantly.

On the other hand I would say, DllPlugin and DllReferencePlugin requires the app developers to have more knowledges about webpack. They need to revisit the webpack config to maintain the pre-build. So I'm not sure whether I should create a pull request or not. Address here to hear your input.

[LinusBorg]

Those two plugins serve different purposes, as I understand it. We should definitely keep CommonsChunkPlugin in the production build, but the DLLPlugin can be useful in the dev build, I agree.

However I also share your hesitation about the beginner-friendliness. In particular, I think that users who work on apps large enough to profit from this setup will have to be proficient with webpack anyway. and can easily add it, whereas users who use the template for prototyping or playing around may feel that this makes it more complicated than it already is.

If you have an idea how to incoprorate the DLLPlugin into the development experience while making it easy for users to deal with it, i'm all ears. :)

[maxmilton]

Please don't add these types of advanced/complex features to the template. I was recently working on a project which used angular2-webpack-starter and the number 1 feedback I would hear is the build process is too complex. The junior devs struggled enough with webpack in general let alone all the extra complexity with the DLLPlugin.

One of the things that attracts me to Vue and the vue+webpack template in particular is its relative simplicity.

I definitely see the benefits of DLLPlugin/DllReferencePlugin on projects with a large number of dependencies but as it stands this template doesn't have that many dependencies that it significantly slows down rebuilds. An option might be forking this idea into a separate template :)

[myst729]

@MaxMilton

As you could read from above discussions, Linus and I also share your concerns. That's why I think it needs to be discussed. I'm thinking of maybe an _opt-in_ feature could balance both sides? Like test and lint functionalities the template provides.

[githoniel]

DllReferencePlugin does no support to async load dll js on demand....

[yugasun]

@myst729 Can you share your configuration of DllPlugin and DllReferencePlugin for webpack template?

[myst729]

After over 9 months I'd rather close the thread. There's a better solution for me right now.

DllPlugin could avoid unnecessary builds of dependencies, if they don't change at all. But, whenever we update, add, or remove one or more packages in production dependencies, the vendor bundle has to be rebuilt. The whole vendor bundle has to be loaded again on client side because you need to update the cache, even if you just changed a 1KB lib!

To make best use of the cache, now I load most of my production dependencies from CDN. That means I don't even have a vendor bundle now. All I need to deploy is my business bundle. When production dependencies update, only the updated packages need to be cached again, others are good as usual. Furthermore, the update could be bypassed too if the packages have already been cached by other sites.

I've talked with several colleagues and they do have similar thoughts. When I tried to implement the idea, I found tools like webpack-cdn-plugin. Very handy for my use case.