avatarTobias Koppers

Summary

The webpack team is actively working on major updates for webpack 4, focusing on WASM support, a new CSS workflow, performance enhancements, and better ESM tree shaking, with plans for breaking changes and a stable release in the near future.

Abstract

The webpack project has seen a significant reduction in open issues, from 700 to 500, due to the implementation of an auto-closing bot for inactive issues. The bot's 15-day warning period allowed the community to revive incorrectly flagged issues, and the team is considering further reducing the inactive period. The development of webpack 4 is underway, with a focus on several key goals such as WebAssembly (WASM) support, a new default CSS packaging method, support for async script tags, performance improvements, optimization for ESM without side-effects, and support for typings in plugins and hooks. These advancements will necessitate breaking changes in the codebase, including new syntax for plugin hooks, module type categorization, runtime code refactoring, and changes to the way dependencies are managed. The team has outlined a comprehensive list of TODOs to achieve these goals, including the implementation of WASM and CSS module types, runtime code adjustments for async script tags, and performance optimization tasks. The webpack 3 version will continue to be supported with bug fixes until webpack 4 is deemed stable. The development process is expected to take at least two months, with a release candidate planned for at least one month before the official release to allow for plugin author testing and updates. The project relies on community donations for funding, with special thanks given to top sponsors such as ag-Grid, Capital One, Segment, Trivago, and AngularClass.

Opinions

  • The auto-closing bot has been effective in managing the issue count on the webpack/webpack repository, with a positive reception from the community in reviving issues.
  • The webpack team values community feedback and has set clear goals for webpack 4, acknowledging the need for breaking changes to achieve these goals.
  • There is an emphasis on improving the developer experience, particularly with the new CSS workflow that will package CSS separately from JS by default.
  • The team is mindful of the impact of breaking changes and plans to provide a backward-compatibility layer to support older code.
  • The project's funding model, which relies on donations, is highlighted as a point of pride and a testament to the community's support for webpack's development.
  • Gratitude is expressed towards the top sponsors, recognizing their significant financial contributions to the webpack project.

Road to webpack 4 (week 20–21)

2017/08/14–2017/08/27

It has been more than 2 weeks after I installed the auto-closing bot for the webpack/webpack repo. There was a warning period of 15 days. This means bot closed all inactive issue → issue count went from 700 to 500 open issues :)

The process worked really great. Many incorrectly flagged issues where revived in the warning period by watchers.

Reviving is pretty easy as you just have to comment on the issue. The bot will automatically remove the inactive label.

Currently issues with 10 or more 👍 are never flagged inactive.

I guess I will lower the time until inactive to get rid of more issues. You should collect 10 👍 to have long-living issues.

Currently the high number of issue hide the important ones…

Planning

The last weeks I did some planning and experimentation with items planned for webpack 4. While webpack 3 didn’t include many breaking changes, webpack 4 probably will.

Goals

These are the main driving goals for webpack 4:

  • WASM support
  • New CSS workflow
  • Support for async script tags
  • Performance improvements
  • Optimization for ESM without side-effects
  • Support typings for plugins/hooks

These goals require some breaking changes:

  • New syntax for hooking into plugin hooks There will be a new tapable version which also include other improvements.
  • Add a type to modules (JS, ESM, WASM, CSS) This requires a lot of refactoring in the Asset Generation.
  • Refactoring of the Runtime code This allows different runtime code for different module type
  • Pushing to array instead of pure JSONP This allows to load chunks in any order on bootstrap.
  • and more minor breaking changes

TODOs

WASM Support

This allows to use WASM modules with webpack in a way that make them feel very like ESM.

  • WASM module type
  • Asset Generation for WASM
  • Runtime code for WASM
  • WASM Parser to extract imports/exports

CSS

This changes the default way for packaging CSS with webpack. Instead of embedding them into JS, webpack will generate CSS assets by default.

  • CSS module type
  • Asset Generation for CSS
  • Runtime code for CSS
  • CSS Parser to extract imports/exports

Async script tag

This allows to load webpack script with <script async> for better bootstrap performance.

  • Changes to chunk loading runtime code wpJSONP = wpJSONP || [];wpJSONP.push(...) instead of wpJSONP(...)
  • Block entry point execution until all required chunks are ready
  • Options to define position to runtime code as it can be in any entry chunk now

Performance improvements

This will improve build performance.

  • Merge outstanding performance PRs
  • Enforce best performance for plugin hooks
  • Refactor more Arrays to Sets

Optimization for ESM without side-effects

This will improve tree shaking of libraries without side-effects.

  • Refactoring for ESM handling to allow more optimizations
  • Add support for "side-effects": false in package.json
  • Reconnect dependencies when side-effect-free modules are involved
  • Remove dependencies to side-effect-free modules when they are not used

Support typings for plugins/hooks

This will allow to write types of plugin hook to improve plugin development.

  • Rewrite tapable to allow typing, promises and improve performance
  • Create backward-compatibility layer to support old code
  • Refactor webpack and internal plugins to use new API

Stable Version

It probably take a while until all these changes are implemented. In this time webpack 3 will be supported as stable version and continue to get bug fixes until webpack 4 is stable enough.

Timeframe

I guess these changes take at least 2 months.

There will be a RC at least 1 month before the Release. This should allow plugin authors to test/upgrade their plugins to the breaking changes.

< week 18–19 week 22–23 >

webpack is not backed by a big company, unlike many other big Open Source products. The development is funded by donations. Please consider donating if you depend on webpack… (Ask your boss!)

Special thanks to these sponsors: (Top 5)

JavaScript
Recommended from ReadMedium
avatarAlexander Nguyen
The resume that got a software engineer a $300,000 job at Google.

1-page. Well-formatted.

4 min read
avatarDemian Kostelny
Lit.js + Vite.js — Quick setup and example

It’s time to begin my showcase of cool front-end frameworks or libraries/tools — and today we are going to talk about Lit.js, and how you…

5 min read
avatarShuai Li
Can You Answer This Senior Level JavaScript Promise Interview Question?

Most interviewees failed on it.

3 min read
avatarTari Ibaba
5 amazing new JavaScript features in ES15 (2024)

5 juicy ES15 features with new functionality for cleaner and shorter JavaScript code in 2024.

4 min read
avatarAfan Khan
Microsoft is ditching React

Here’s why Microsoft considers React a mistake for Edge.

6 min read
avatarSufyan Maan, M.Eng
What Happens When You Start Reading Every Day

Think before you speak. Read before you think. — Fran Lebowitz

7 min read