Before I used webpack common chunks plugin to create vendor bundle containing third party libraries like angular, react, lodash etc, but then I knew about webpack dll plugin. They seem do the same things but dll plugin also allows you to reduce build time. So I'm confused do I need to use both these plugins together. Should I use common chunks plugin for creating vendor bundle in production build and dll plugin in development build. Or I should use dll plugin in both production and development builds? Could you please explain this?
Asked
Active
Viewed 9,406 times
3 Answers
35
Sorry for long answer, but let's hope it can help make things clearer.
CommonsChunkPlugin rationale
Project author defines a number of application entry points that will produce a bundle each. Typical examples are vendor, polyfills, main, but for example your app could be split in several independent "areas" that makes sense to load separately (like e.g. login, main, settings).
Project author then defines which one of those bundles, or a separate one, should contain code common to all of them. That is tipically 3rd party libraries and your own shared utilities across all entry points.
Then it is plugin responsibility to analyze and collect such common code, then put it in defined bundle. All such analysis and work happens again and again everytime you start a new build, and - in watch mode - when you modify code that is shared and happens to fall into commons bundle.
Such a split is useful both for a development build as well as for a production build. But for dev environment, let's just say that re-building code related to vendors and polyfills might take quite some time and it can be a waste when you're not really changing those parts (assuming 3rd party code you depend on is larger than your own codebase).
DllPlugin rationale
Given the same environment, for example development, project author creates two webpack configurations where there used to be one. The plugin could be applied to production environment, although it can be said that DllPlugin makes more sense in development (see below).
First webpack build configuration is needed for so-called DLLs, which are kind of close to the commons code seen before, but not exactly. To my understanding, DLLs mostly tend to group 3rd party code (vendor and polyfills) and not your own shared utility code, but again this is more an impression and not a strict rule. Anyway, here project author should group code that changes much less frequently during a normal development session. The idea, in dev environment, is to run this build every once in a while, for example when a dependency changes. And usually it is up to the developer to fire this build when s/he think is needed.
The other webpack build configuration is needed for project own code, or anyway code that changes regularly while doing dev work. This is the actual build that developer will run again and again, or will run in watch mode, and at this point it should be very much quicker as compared to the single build seen in CommonsChunk scenario.
So, all in all, they seem similar, but they let you hit different targets. So much, that you could consider using DllPlugin for your dev environment (advantage: short compile time), while using CommonsChunkPlugin for production (advantage: short load time when app changes). Again, you could as well use DllPlugin also in production, with the small inconvenience of having to run two builds in a row: one for DLLs, next the one for the app.
HTH
superjos
- 12,189
- 6
- 89
- 134
-
Actually if you use the DllPlugin for development, the production build can leverage the same pre-built DllPlugin output. Isn't it true? – ozanmuyes Nov 27 '17 at 00:40
-
I'm not sure I would do that. Usually I include a clean step before doing production build, so to be sure not to bring any old output over to production env. Also I would not mix outputs from both builds, as a principle (not sure DllPlugin output changes between the two builds). – superjos Nov 27 '17 at 16:07
-
Yes you are right, clearing the output directory is a good habit. Even though I don't think the output of the DllPlugin will differ build to build when environment changes (since 'devDependencies' are out of its scope and it only depends on 'dependencies') it is better this way (e.g. [clean-webpack-plugin](https://github.com/johnagan/clean-webpack-plugin)). – ozanmuyes Nov 29 '17 at 01:13
11
You use one or the other. Here is an article, which describes how to use DllPlugin and down at the bottom of the page you can see alternative methods of accomplishing the same thing. It tells you what the differences are as well as advantages and disadvantages. This should get you started.
chemoish
- 1,210
- 2
- 13
- 23
user981375
- 639
- 1
- 5
- 15
4
I was looking for the difference here as well but I really don't think this is the case. At least, not anymore.
If you take a look at the webpack documenation for code splitting libraries, it mentions a way to extract out a similar manifest file. From my understanding, this is what the DllPlugin is doing except it is slightly more implicit with the CommonsChunkPlugin.
The benefit is that you don't need to maintain multiple Webpack configurations for this sort of functionality.
