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!
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 add webpack@next webpack-cli --dev
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 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
productionmode, 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
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) between two modes now:
- 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
- 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
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
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.
???? Module Type’s Introduced + .mjs support
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
.jsonextensions 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!
Webpack now by default supports
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:
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.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! ❤