Remember how exciting it was when webpack 2 was released? We decided to use this same cover photo from our v2.2 release because it reminds us of this excitement!!!

🎼webpack 4: released today!!✨

Codename: Legato 🎶

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

🎼 Why Legato?

We wanted to start a new tradition by giving each of our major releases a codename! Therefore, we decided to give this privilege to our largest OpenCollective sponsor: trivago!

So we reached out and here was their response:

[At trivago] we usually give our projects a name with a musical theme. For example, our old JS Framework was called “Harmony”, our new framework is “Melody”. On the PHP side, we use Symfony with a layer on top called “Orchestra”.
Legato means to play each note in sequence without gaps.
Webpack bundles our entire frontend app together, without gaps (JS, CSS & more). So we believe that “legato” is a good fit for webpack — Patrick Gotthardt at trivago Engineering

We were thrilled, because everything we worked on this release encapsulates this idea webpack feeling legato, or without gaps, when you use it. Thank you so much to trivago for this incredible year of sponsorship and for naming webpack 4! 👏👏

🕵️‍What’s new?

There are so many new things in webpack 4, that I can’t list them all or 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)!

We were seeing interesting reports of build performance from the community testing our beta, so I shot out a poll so we could verify our findings:

Feel free and respond to this tweet with your before or after story! I’m hoping to compile these to a separate medium publication!

The results were startling. Build times decreased from 60 to 98%!! Here are just a few of the responses we’ve seen.

These are just a few of the build speed success stories. See the rest of the twitter thread for more of them!!

This also gave us the opportunity to identify some key blocking bugs in loaders and plugins that have since now been fixed!! PS: we haven’t implemented Multicore, or Persistent Caching yet (slated for version 5). This means that there is still lot’s of room for improvement!!!!

Build speed was one of the top priorities that we had 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 we’ve 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

We introduced a new property 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.

To see all of the details behind mode, you can check out our previous medium article here:

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!

Legato means to play each note in sequence without gaps.

With all these things, we now have 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!

For more information on why we did this, and what the API looks like, see this post!!

🔬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. We have 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 .json extensions in this order to resolve

What’s most exciting about this feature, is that now we can continue to work on our CSS and HTML module types (slated for webpack 4.x to 5). This would allow capabilities like HTML as your entry-point!

🛑 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#a8a8c2

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!

If you own other plugins and loaders, you can see our migration guide here:

💖And so much more!

There are so many more features that we heavily recommend you check them all out on our official change log.

🐣 Where’s the v4 Docs?

We 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 we have 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 sideEffects flag, 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].

😒Why do you use so many emojis?

Because we can have fun while creating an incredible product! You should try it sometime 😍.

Sorry to hear friend! I’ll personally send you a screen shot of each one if you’d like 😍😍

🎨 Whats next?

We have already started planning our next set of features for webpack 4.x and 5! They include (but are not limited to):

  • ESM Module Target
  • Persistent Caching
  • Move WebAssembly support from experimental to stable. Add tree-shaking and dead code elimination!
  • Presets — Extend 0CJS, anything can be Zero Config. They way it should be.
  • CSS Module Type — CSS as Entry (Goodbye ExtractTextWebpackPlugin)
  • HTML Module Type — HTML as Entry
  • URL/File Module Type
  • <Create Your Own> Module Type
  • Multi-threading
  • Redefining our Organization Charter and Mission Statement
  • Google Summer of Code (Separate Post Coming Soon!!!)

🙇 Thank you. Again. 🙇

To all of those involved on our contributor team, the core team, loader and plugin authors, those who submitted their first time commits, or assisted with troubleshooting: we cannot thank you enough. This product is for you and helped shaped by you.

2018 is about removing our fixed mindset, and start seeing JavaScript for the beautiful Renaissance it is! ❤

We have said this many times in the past, but the community is what makes webpack strong, sustainable, and vibrant in this JavaScript Renaissance we live in today. Without you all, webpack would still be Yet Another Build Tool (YABT).


No time to help contribute? Want to give back in other ways? Become a Backer or Sponsor to webpack by donating to our open collective. Open Collective not only helps support the Core Team, but also supports contributors who have spent significant time improving our organization on their free time! ❤