Today we’re happy to release that webpack 4 (Legato) is available today! You can get it via yarn or npm using:

$> yarn add webpack --dev

or

$> npm i webpack --save-dev

What’s new?

There are so many new things in webpack 4, and listing them in this post would last forever. Therefore I’ll share a few things, and to see all of the changes from 3 to 4, please review the release notes & changelog.

webpack 4, is FAST (up to 98% faster)!

Build speed was one of the top priorities that they had for this release. One could add all the features in the world, however if they are inaccessible and waste minutes of dev time, what’s the point? This is just a few of the examples were seen so far, but we really look forward to having you try it out and report your build times with #webpack #webpack4 on twitter!

Mode, #0CJS, and sensible defaults

A new property was introduced for your config called mode. Mode has two options: development or production and defaults to production out of the box. Mode is our way of providing sensible defaults optimized for either build size (production) optimization, or build time (development) optimization.

In addition, entry, output are both defaulted. This means you don’t need a config to get started, and with mode, you’ll see your configuration file get incredibly small as we are doing most of the heavy lifting for you now!

With all these things, there is a platform of zero config that we what you to extend. One of webpack’s most valuable feature is that we are deeply rooted in extensibility. Who are we to define what your #0CJS (Zero-Config JS) looks like? When we finish the design and release of our webpack presets design, this means you can extend #0CJS to be unique and perfect for your workflow, company, or even framework community.

Goodbye CommonsChunkPlugin

We have deprecated and removed CommonsChunkPlugin, and have replaced it with a set of defaults and easily overridable API  called optimize.splitChunks. Now out of the box, you will have shared chunks automatically generated for you in a variety of scenarios!

WebAssembly Support

Webpack now by default supports import and export of any local WebAssembly module. This means that you can also write loaders that allow you to import Rust, C++, C and other WebAssembly host lang files directly.

Module Type’s Introduced + .mjs support

Historically, JavaScript has been the only first-class module type in webpack. This caused a lot of awkward pains for users where they would not be able to effectively have CSS/HTML Bundles, etc. Now, a completely abstracted the JavaScript specificity from our code base to allow for this new API. Currently built, we now have 5 module types implemented:

  • javascript/auto(The default one in webpack 3) JavaScript module with all module systems enabled: CommonJS, AMD, ESM
  • javascript/esm: EcmaScript modules, all other module system are not available (the default for .mjs files)
  • javascript/dynamic: Only CommonJS & AMD; EcmaScript modules are not available
  • json: JSON data, it’s available via require and import (the default for .json files)
  • webassembly/experimental: WebAssembly modules (currently experimental and the default for .wasm files)
  • In addition webpack now looks for the .wasm.mjs.js and .jsonextensions in this order to resolve

If you use HtmlWebpackPlugin

For this release, we gave the ecosystem a month to upgrade any plugins or loaders to use the new webpack 4 API’s. However, Jan Nicklas has been away with work obligations and therefore, we have provided a patched fork of html-webpack-plugin . For now you can install it by doing the following:

$> yarn add html-webpack-plugin@webpack-contrib/html-webpack-plugin

When Jan returns from overseas work at the end of the month, we plan to merge our fork upstream into jantimon/html-webpack-plugin ! Until then, if you have any issues, you can submit them here!

Where’s the v4 Docs?

The team are very close to having out Migration Guide and v4 Docs Additions complete! To track the progress, or give a helping hand, please stop by our documentation repository, checkout the next branch, and help out!

What about <framework>-cli?

Over the past 30 days the team has worked closely with each of the frameworks to ensure that they are ready to support webpack 4 in their respective cli’s etc. Even popular library’s like lodash-es, RxJS are supporting the sideEffectsflag, so by using their latest version you will see instant bundle size decreases out of the box.

The AngularCLI team has said that they even plan on shipping their next major version (only ~week away) using webpack 4! If you want to know the status, reach out to them, and ask how you can help [instead of when it will be done].