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 single export 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

: (The default one in ) 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)

: EcmaScript modules, all other module system are not available (the default for .mjs files) javascript/dynamic : Only CommonJS & AMD; EcmaScript modules are not available

: Only CommonJS & AMD; EcmaScript modules are not available json : JSON data, it’s available via require and import (the default for .json files)

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

: 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 CommonsChunkPlugin and 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.