Webpack 4 (The Quick and Dirty)
The release of Webpack 4 (dubbed Legato) brings several exciting changes, the biggest being that Node 4 is no longer supported, and development has shifted to support the newer ES6 specification. ES6 has better optimization with V8, which results in quite a nice boost in performance (numbers below!). In addition, the developers of Webpack boast that v4 is now a zero configuration bundling tool! This upgrade is huge win because, in the past, one of the biggest pain points in getting started with Webpack was setting up the webpack.config.js file. But with the new zero configuration model, webpack is delivering a bunch of niceties out of the box, ready to go. They’ve completely removed the need for CommonsChunkPlugin and now deliver their own solution to handle shared chunks automatically for the user.
Production & Development
Wave buh-bye to having split config files with 2 different sets of plugins for production and development. Previously, a common solution to not uglifying the code and getting it ready for production was to effectively have 2 different webpack.config files with different sets of plugins. This has been replaced with the new mode (–mode) flag. Now you simply have to add these scripts to your package.json:
webpack --mode production webpack --mode development
These scripts will both generate a bundled file (main.js), but the production flag will do a slew of optimization (hoisting, tree shaking, minification) on your code and modules. Development mode on the other hand is not minified, and is optimized for speed rather than bundle size.
What They Really Mean
webpack --mode <environment> <entry path> --output <output path>
Now for the juicy data (probably all you cared about). An important note: Previously, the project was not using gzip compression, but with the migration to Webpack 4 I added it to the config.
Before (Webpack 3):
After (Webpack 4):
The results are output in different UoMs (Webpack changed their output to the IEC binary standard). This means Webpack 4 displays the bundle size in MiB rather than MB, so (2^20 vs 10^6 bytes). This ultimately results in a difference in bundle size of ~148KiB between the main.js and bundle.js files you see above.
As you can see, the performance boost of webpack 4 is pretty nice! Bundling time is significantly reduced. NB: There are many variables that affect bundling time, so take these results with a grain of salt, but, many other users have reported significantly faster bundle times. Also evident from the output is how much work gzip is doing for us in reducing the bundle size to 317KiB from the 1.14MiB bundle, that’s a vast amount of space saved.
While playing with webpack 4, and now questioning the sizes of everything on the OS, I found a nifty plugin which displays the contents of the bundle as a size map! (I know, it’s pretty awesome, and you would love to see it).
So there it is! All the stuff in the bundle. Not surprisingly most of the bundle size is from node_modules. Perhaps more surprisingly was the size of the moment module, seeing as none of my team members remembered ever using moment for anything. It turns out moment is a sub dependency of an internal monsanto navigation bar module.
- Webpack 4 is fast
- Webpack 4 is zero config (erhm..)
- Webpack 4 –mode makes your .config super clean
- gzip saves you a bunch of space
- webpack-bundle-analyzer gives you insight into what’s in the bundle