To support millions of features, use-cases, and needs, it takes a secure, stable, reliable, and scale-able foundation. Only with webpack, are the possibilities limitless!

🚀webpack 4 beta — try it today!🚀

The road to stable release!

Since the beginning of August — when we forked webpack/webpack#master for the next branch — we’ve seen an incredible influx of contributions!

Git contribution stats for the webpack next branch at a glance using gitinspector! Try it on your project to see insights. PS: This doesn’t include the incredible work done in our webpack-cli team and webpack-contrib organization supporting our loaders and plugins.

🎉 Today, the we are proud to share the culmination of that work by releasing webpack 4.0.0-beta.0! 🎉

🎁A Promise Fulfilled — Predictable Release Cycle

When we finished the release of webpack 3, we promised the community that we’d give you a longer development cycle between major versions.

We’ve delivered on that promise [and continue to deliver on it] by bringing you a great set of features, improvements, and bug fixes that we can’t wait for you to get your hands on! Here’s how you get started!

🤷‍How to install [v4.0.0-beta.0]

If you are using yarn:

yarn add webpack@next webpack-cli --dev

or npm:

npm install webpack@next webpack-cli --save-dev

🛠How to migrate?

The more folks trying and reporting plugin and loader incompatibilities while testing webpack 4, the more we can build up a living migration guide.

So we need you to check out the official change log, and also our migration draft and provide feedback where missing! This will help our documentation team create our official stable release migration guide!

What’s new in webpack 4?

Below are some of the more notable features that you will enjoy reading about. For the full list of changes, features, and internal API modifications, please refer to our change log!!!

🚀Performance

Performance will be significantly enhanced in multiple scenarios for webpack 4. Here are just a few of the notable changes we made to accomplish this:

  • By default, when using production mode, we will automatically parallelize and cache the minification work done by UglifyJS.
  • We shipped a new version of our plugin system so that event hooks and handlers are monomorphic.
  • In addition, webpack now has dropped Node v4 support, allowing us to add a considerable amount of newer ES6 syntax and data structures, also optimized by V8. So far we have seen real-life reports of 9h to 12min!

PS: we haven’t even implemented full caching and parallelism 😉 [webpack 5 milestone].

🔥Better Defaults — #0CJS

Up until today, webpack has always required you to explicitly set your entry and output properties. With webpack 4, webpack will automatically assume your entry property is ./src/ and bundles will output to ./dist by default.

This means that you no longer need a configuration to get started with webpack!!!

webpack 4.0.0-beta.0 running a build w/o a configuration! #0CJS 🔥

Now that webpack is a #0CJS (Zero Configuration) out-of-the-box bundler, we will lay groundwork in 4.x and 5.0 to provide more default capabilities down the road.

💪Better Defaults — mode

You have to choose (mode or --mode) between two modes now: “production” or “development”.

  • Production Mode enables all sorts of optimizations out of the box for you. This includes, minification, scope hoisting, tree-shaking, side-effect-free module pruning, and includes plugins you would have to manually use like NoEmitOnErrorsPlugin.
  • Development Mode optimized for speed and developer experience. In the same way, we automatically include features like path names in your bundle output, eval-source-maps, that are meant for easy-to-read code, and fast build times!

🍰sideEffects — Huge win for bundle sizes

We introduced support for sideEffects: false in package.json. When this field is added, it signals to webpack that there are no sideEffects in the library being consumed. This means that webpack can safely eliminate any used re-exports from your code.

For example, importing only as singleexport from lodash-es would cost ~223 KiB [minified]. In webpack 4, this cost is now ~3 KiB!!!

We originally called this feature “pure-module”. This is now called “sideEffects”

🌳JSON Support & Tree Shaking

When you import JSON with ESModule syntax, webpack will eliminate unused exports from the “JSON Module”. For those who are already importing JSON into your code with lot’s of unused pieces, you should see a significant size decrease in your bundle sizes.

😍Upgrade to UglifyJS2

This means that you can use ES6 Syntax, minify it, without a transpiler first.

We would like to thank the UglifyJs2 team of contributors for the selfless and hard work they have done to land ES6 support. This was no easy task and we’d love for you to stop by their repository and express your appreciation and support.

UglifyJS2 now supports ES6 JavaScript syntax!

🐐 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 (4.x). This would allow capabilities like HTML as your entry-point!

🔬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:

💀Goodbye CommonsChunkPlugin

We have also removed CommonsChunkPluginand enabled many of its features by default. In addition, for those who need fine-grained control over their caching-strategy, we have added optimization.splitChunks and optimization.runtimeChunk with a richer, more flexible set of capabilities

💖And so much more!

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

⌚The clock starts now

As promised, we will wait a month from today before releasing webpack 4 stable. This gives our plugin, loaders, and integrations ecosystem time to test, report, and upgrade to webpack 4.0.0!

We need you to help us upgrade and test this beta. The more we can have testing it today, the faster we can help triage and identify any issues that could come up down the road!

Thank you so much to all of our contributors who have helped make wepback 4 what it is today. As we always say, webpack’s power is the sum of our parts and ecosystem.


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! ❤