There have been a few changes in Webpack since my last blog in February 2017. The original blog was written for version 2 and Webpack is now in stable version 4 with version 5 being in beta release. In this blog, I will take a look at the changes that can make our lives easier again.
Webpack CLI and node support
Webpack dropped Node v4 support (minimal required version is 8 now) in order to allow use of new language syntax and data structures from newer node versions and it split into two separate packages. Webpack core functionalities can be found in the
webpack package and you can use this package in your node scripts. If you want to use Webpack in CLI, you have to instal the
webpack-cli package too.
webpack -mode=(production||development) in your CLI. It uses
src/index.js as the entry point and it serves bundles into
Have you noticed the mode option in the previous section? Since version 4, Webpack provides two modes (“production” and “development”) that affect its default configuration. It also moved some plugins into defaults so you don’t have to care about them. All the changes can be found in the migration guide. You can override defaults for both modules in a Webpack config.
In the production mode, Webpack provides optimizations like minification, tree-shaking, side-effect-free module pruning or scope hoisting out-of-box.
The development mode supports developer experience with path names in the bundle output or eval-source-maps.
Since version 4, Webpack by default checks “package.json” of every package bundled into your app and if it includes
sideEffects: false statement, Webpack can safely tree-shake the package. This is a huge win for the bundle size and the bundling speed.
Isn’t Webpack obsolete?
After Webpack became popular, a few other projects showed up to eliminate problems Webpack was suffering from. Don’t you like to configure everything? Don’t you like the runtime code of Webpack? Do you think Webpack is slow? You can use bundlers like Rollup or Parcel.
Rollup was created to speed up bundling and to create smaller bundles. It is achieved by focusing only on the ES6 module format. Parcel, on the other hand, focuses on a minimal needed configuration and it supports HTML files as entry points too.
If you want to know more about the differences between the bundlers, you can read for example this article. Things aren’t that easy and straightforward these days. Webpack made a huge step forward with its performance in version 4 and it decreased the runtime code size too. It even added the mode option to make configuration less painful. Version 5 plans to add full caching and parallelism to make Webpack even more performant. In the end, it depends on your priorities and you should try all of the bundlers to find the one that fits your project most. If you don’t want to run complex benchmarks to find out, I would suggest using Webpack because of the huge community it has.
As you can see, Webpack is still evolving. It learned from previous mistakes and tries to be more user friendly with simplifying configuration. They are working on performance and it should be even better in version 5 with caching and parallelism. There are other bundlers that you can use, but Webpack is the most mature of them and still has a lot to say.
If you want to read more about the changes in Webpack, I would recommend you following links:
- Webpack 3 announcement
- Webpack 3 migration guide
- Webpack 4 changelog
- Webpack 4 announcement
- Webpack 4 migration guide
Did you know?
There are some smaller changes and cool stuff you might have never even thought about doing in Webpack. So, did you know:
- config file can export an array? For example if you support more targets (node, browser) with your app or library.
- config file can export a function? It is later invoked with params like mode or environment variables from the webpack CLI command.
- you can use TypeScript for your Webpack config to support config hinting?
- Webpack supports importing JSON files by default?
- you can import or export any local WebAssembly module?
- you can use “magic comments” for dynamic imports? It is handy if you want to fine tune how Webpack handles them.