webpack
diff --git a/‎src/content/blog/2026-04-02-roadmap-2026.mdx‎
Lines changed: 124 additions & 29 deletions b/‎src/content/blog/2026-04-02-roadmap-2026.mdx‎
Lines changed: 124 additions & 29 deletions
@@ -3,62 +3,157 @@ title: Roadmap 2026 (2026-02-04)
 sort: 9
 contributors:
   - evenstensberg
+  - bjohansebas
 ---
 
 Hello from the webpack Technical Steering Committee member [Even](http://x.com/evenstensberg)!
 
-The different contributors in the organization are working hard to ensure that webpack is still a good alternative to building your web applications. Even though there has emerged a lot of different tools lately, we hope that using webpack as a stable choice is still an option for you. 
-Our work this year is not only focused on improving existing functionality, but also work on some new things that might be beneficial in other ways. 
+The different contributors in the organization continue to work on ensuring that **webpack remains a solid and reliable tool** for building web applications. While many new tools have emerged, webpack continues to be a **stable and well-supported choice**.
 
-## So what is on our agenda this year? Let me walk you through it!
+## Here’s what we’re excited about for 2026
 
-- **CSS modules** — built-in CSS support in webpack (≈90%). Native CSS support [webpack#14893](https://github.com/webpack/webpack/issues/14893). ETA: Feb–Mar.
+In 2026, our focus goes beyond maintaining existing features. We’re investing in improvements that make webpack easier to use and maintain, while also pushing forward ideas that prepare the project for modern runtimes, evolving development patterns, and the long-term health of the ecosystem.
 
-- **Universal target** — works across Node.js, browsers, Deno, and Bun (≈98%). Finish CommonJS wrapper, add `target: "universal"`, and expand tests. Outputs ESM only; write environment-agnostic code.
+Below, we’ll walk through the main areas we’re actively working on and the ideas we plan to develop throughout the year.
 
-- **TypeScript** — built-in support. [`enhanced-resolve`](https://github.com/webpack/enhanced-resolve) honors [`tsconfig.json`](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html). Add parser wrapper to `module.javascript.parse`, improve resolver for `ts/cts/mts`, support `extensionAlias`, and add tests.
+### Support for CSS Modules without the need for plugins
 
-- **HTML modules** — first-class HTML: import HTML files and use HTML entry points. Aim to replace `html-webpack-plugin`. See [webpack#536](https://github.com/webpack/webpack/issues/536).
+There is currently an [`experimental.css`](/configuration/experiments/#experimentscss) option, which enables **native CSS support** without the need to add plugins to your configuration, as was previously required with plugins like [`mini-css-extract-plugin`](/plugins/mini-css-extract-plugin).
 
-- **ESM output** — fixes and improvements. See [webpack#17121](https://github.com/webpack/webpack/issues/17121).
+The development is already quite advanced, with the possibility of finishing the inclusion into webpack core around **February/March**. After that, the support would remain _experimental_ for a while to gather bug reports, but in **webpack 6** it will no longer be experimental and **plugins for this task will no longer be necessary**.
 
-- **Webpack everywhere** — build webpack for Node and web (including universal), reduce Node internals and Buffer usage, add a site playground.
+You can follow the discussion about [experimental CSS support](https://github.com/webpack/webpack/issues/14893)
+to stay updated and contribute ideas.
 
-- **Deno & Bun** — Deno supported; add tests. Bun: assess and test.
+### A universal target to make your code compatible across runtimes
 
-- **Lazy barrel** — evaluate Rspack’s approach.
+The idea is to add a new target called **universal**, which will compile your code so it can run across **different runtimes**, including Node, the web, Bun, Deno, etc.
+Regardless of whether you use **CommonJS modules** in your application, webpack will be able to wrap them, and all the resulting code will be **pure ESM**, making it _runtime-agnostic_.
 
-- **Dev tooling** — merge `webpack-dev-middleware` and `webpack-hot-middleware`. Extract overlay from dev-server and consolidate overlay + WS/EventSource logic for reuse. Add plugin support to dev-server.
+There has already been significant progress toward this goal, but **ESM output is not fully finished yet**. Additional fixes and improvements are still required (see [webpack#17121](https://github.com/webpack/webpack/issues/17121)), along with **adding missing tests** and completing the _CommonJS wrapper functionality_.
 
-- **CLI** — consolidate packages, refactor help and subcommand logic. See [webpack-cli#4619](https://github.com/webpack/webpack-cli/issues/4619).
+You can also join the discussion about [universal target](https://github.com/webpack/webpack/issues/6525) to share your ideas or follow updates on cross-runtime compatibility.
 
-- **Docs & site** — auto-generate options docs from webpack schemas/types into JSON, then render Markdown on the site. Priority: accurate, complete docs.
+### Support for building TypeScript without loaders
 
-- **Minimizers** — combine `terser-webpack-plugin`, `css-minimizer-webpack-plugin`, `html-minimizer-webpack-plugin`, and `json-minimizer-webpack-plugin` into one `minimizer-webpack-plugin`.
+Recently, in version [5.105](/blog/webpack-5-105/) we included support for **resolving the paths defined in the TypeScript configuration**, eliminating the need to use a plugin ([tsconfig-paths-webpack-plugin](https://www.npmjs.com/package/tsconfig-paths-webpack-plugin)). Now we want to further expand TypeScript support by **removing the need to use a loader** (the most common one being _ts-loader_) to transpile TypeScript directly in webpack, which would also **reduce your project’s dependencies**.
 
-- **Multithreading API** — bring ideas from [`thread-loader`](https://github.com/webpack/thread-loader) into core; needs design discussion.
+### Import HTML files and use them as entry points without the need for plugins
 
-- **Design** — new design assets for projects and swag.
+Currently, to import HTML files and use them as entry points, it’s necessary to use a plugin ([_html-webpack-plugin_](/plugins/html-webpack-plugin)). The idea is to **integrate that plugin into the core**, similar to how CSS Modules are being handled, and remove the need for a plugin for such a common task. Like CSS Modules, this would be introduced as an _experimental option_, so that in **webpack 6** you’ll be able to remove that dependency.
 
-- **Community** — outreach via articles and conferences.
+You can follow the idea and its progress in [webpack#536](https://github.com/webpack/webpack/issues/536).
 
-- **GSoC** — mentor students starting their OSS journey.
+### Webpack Everywhere (Node, Deno, and Bun, Web)
 
-- **Donations** — grow sponsorships to sustain maintenance.
+Node.js is still the **default runtime** for many projects, but times have changed and it’s no longer the only JavaScript runtime. New options like **Deno** and **Bun** have gained significant popularity, and webpack should work seamlessly across all of them.
 
-## Other tasks
+The goal is to build webpack so it can run **everywhere**: in Node.js, in web environments, and in alternative runtimes like Deno and Bun. Even when using modules traditionally tied to Node.js, such as `node:fs`, webpack will intelligently handle them, enabling code that depends on these modules to **run in the browser** or other environments where these modules don’t exist.
 
-- Move `loader-runner` into core to unify loader context logic.
-- Reduce internal TODOs in preparation for webpack@6.
-- Improve test coverage.
-- Strengthen type coverage (fewer `any/unknown/...`).
-- Add more benchmarks (potentially merge with [`webpack/benchmark`](https://github.com/webpack/benchmark)) and CI to compare versions.
+To achieve this, we need to **reduce reliance on Node.js internals** and _Buffer usage_, move toward a **more runtime-agnostic architecture**, and expand test coverage.
 
+Currently, **Deno support is missing proper tests**, while **Bun still lacks required assets and corresponding tests**. In addition, this effort includes adding a **site playground** to validate and showcase webpack running across different environments.
+
+### Evaluating Lazy Barrel Optimization
+
+One interesting idea to explore is **lazy barrel optimization**, inspired by how _Rspack_ handles certain module patterns. In Rspack, _lazy barrel_ is an optimization that **skips building unused re-exported modules in side‑effect‑free barrel files until they’re actually needed**. This can significantly reduce build work, especially in **large codebases** with lots of grouped exports.
+
+Barrel files are modules that **re-export other modules** to create a convenient API surface. For example, a `components/index.js` that exports every component from a directory. While useful for organizing code, traditional bundlers often build _all_ the re-exported modules even if only one is used, which can hurt performance. With _lazy barrel optimization_ in Rspack, **only the modules actually referenced get built**, skipping the rest and improving overall build speed.
+
+Evaluating Rspack’s approach gives us an opportunity to see whether a **similar strategy could benefit webpack**, improving performance around commonly used barrel patterns without requiring developers to restructure their exports manually. It’s an example of looking outward at innovations in the ecosystem to inform possible future enhancements for webpack.
+
+### Simplifying Asset Minimization in Webpack
+
+Webpack currently relies on **multiple separate minimizer plugins**, such as `terser-webpack-plugin`, `css-minimizer-webpack-plugin`, `html-minimizer-webpack-plugin`, and `json-minimizer-webpack-plugin`. While each one works well on its own, **managing them individually adds extra configuration and maintenance overhead**.
+
+The idea is to **combine all of these into a single `minimizer-webpack-plugin`**, providing a more **unified and consistent minimization experience**. This would **simplify configuration**, reduce duplication, and make it easier to extend and maintain minimization logic across different asset types.
+
+### Streamlining Webpack’s Dev Experience
+
+Webpack’s **development and CLI tools** are being improved to enhance maintainability while also introducing **new features** for contributors and users alike.
+
+#### Dev Tooling
+
+Efforts in dev tooling focus on **improving webpack’s internal development workflow** and making it easier to extend and maintain. This includes **merging webpack-dev-middleware and webpack-hot-middleware**, **extracting the overlay from dev-server**, and **consolidating overlay + WebSocket/EventSource logic for reuse**.
+
+Additionally, **plugin support** will be added to the dev-server, enabling more flexibility and reducing duplication. These improvements streamline development for contributors while keeping webpack **flexible and reliable** for users.
+
+#### CLI Improvements
+
+The CLI is being refined to **simplify maintenance** and **improve usability**. Work includes **consolidating packages**, **refactoring help and subcommand logic**, and **improving the overall developer experience** (see [webpack-cli#4619](https://github.com/webpack/webpack-cli/issues/4619)).
+
+These changes make it easier for contributors to maintain the CLI while also providing **practical enhancements** for developers working with webpack in their projects.
+
+You can follow the [webpack-cli improvements](https://github.com/webpack/webpack-cli/issues/4619) discussion to stay updated.
+
+### Accurate and Reliable Documentation
+
+The idea is to **enable automatic generation of all API and configuration documentation** directly from webpack’s **types and schemas**, ensuring the documentation **always matches the actual behavior** of the code.
+
+This approach addresses long-standing problems with **incomplete, outdated, or inconsistent documentation** on the webpack website, and makes it easier to maintain. The goal is to provide developers with **accurate, reliable, and up-to-date references** they can trust.
+
+### Community Outreach and Engagement
+
+Following improvements to documentation and the site, another key focus is **building and strengthening the webpack community**. This year, the effort began with a **new blog launched for webpack 5.105**, and the idea is to continue expanding it through **articles, conference talks, and other public channels**.
+
+By engaging the community, webpack can **grow adoption**, receive **valuable input**, and create stronger connections between the project and its users. Outreach efforts also help ensure that improvements, tutorials, and best practices reach a **wider audience**, making the ecosystem more vibrant and sustainable.
+
+### Multithreading API
+
+Webpack is exploring a **Multithreading API**, inspired by _thread-loader_, to bring **better parallel processing capabilities** into the core.
+
+The goal is to allow webpack to take advantage of **multi-core systems**, improving build performance for **large projects**. This effort is still in the **design and discussion phase**, aiming to create a solution that is **flexible, maintainable, and easy to use**.
+
+By integrating multithreading in a more formal way, webpack hopes to provide developers with **faster builds** while keeping the configuration and internal logic **clean and scalable**. This work reflects ongoing exploration rather than a finalized feature, and _thread-loader_ remains the current **community-supported solution** for parallelization.
+
+### Design and Visual Identity
+
+We want to **improve webpack’s overall visual identity** by creating **new design assets** for projects and swag. This includes things like **banners, clothing merch, water bottles, coffee cups, socks**, and other branded materials.
+
+Beyond making webpack look **more polished and recognizable**, these assets also open the door to **future merchandise sales**, where purchasing swag would directly help fund and support webpack’s ongoing development.
+
+### GSoC Mentorship
+
+A key focus is **mentoring students through the Google Summer of Code (GSoC) program**, a volunteer-driven effort with the goal of teaching them how to **effectively maintain open source projects**.
+
+Through hands-on guidance, students learn **workflows, best practices**, and how to approach maintaining a codebase. At the same time, this mentorship allows the project to **develop new features**, as students work on functionalities that are needed while being guided by experienced contributors.
+
+This experience equips them with the skills needed to become **future maintainers**, contributing not only to webpack but also to the **broader open source ecosystem**, which relies heavily on volunteers.
+
+By emphasizing **maintainability, knowledge transfer**, and **guided feature development**, GSoC mentorship helps secure **long-term sustainability** and cultivates the **next generation of contributors** for open source projects.
+
+### Donations and Sponsorships
+
+Open source projects like webpack are maintained primarily by **volunteers**, and there isn’t a full-time engineering team dedicated to the project.
+
+**Growing donations and sponsorships** is crucial because the more funding available, the more time the core contributors can dedicate to **maintaining and improving webpack**, despite having other responsibilities and personal lives.
+
+Support through donations not only helps **sustain ongoing maintenance** but also enables contributors to focus on **new features, bug fixes**, and **improving the ecosystem** overall. By contributing financially, the community directly helps ensure webpack remains **healthy and actively developed**.
+
+### Preparing for Webpack 6
+
+All the efforts covered in this blog, from enhancing runtime support (Node, Deno, Bun, and universal targets), improving documentation and developer tooling, mentoring new contributors through GSoC, to exploring multithreading and optimizations like lazy barrel, are paving the way toward **webpack 6**.
+
+#### Core and Loader Improvements
+
+To prepare for **webpack@6** and simplify internal logic, efforts include **moving loader-runner into core** to unify loader context handling. This helps reduce duplication, improves maintainability, and lays the groundwork for future enhancements.
+
+Additionally, **reducing internal TODOs across the codebase** ensures a **cleaner foundation** and makes it easier for contributors to work efficiently.
+
+#### Testing and Type Coverage
+
+**Improving test coverage** and **strengthening type coverage** are key priorities. By reducing the use of `any`, `unknown`, and other loose types, webpack becomes **more reliable** and easier to maintain. Strong types and thorough tests help **catch issues earlier** and improve confidence for contributors making changes.
+
+#### Benchmarks and Performance
+
+To measure progress and maintain **high performance standards**, webpack plans to **add more benchmarks**. Integrating these benchmarks into CI pipelines allows **comparisons across versions**, ensuring that optimizations continue to deliver **tangible improvements** for developers.
 
 ## Final remarks
 
-I hope that you found this list useful and that you are excited for 2026, we are! One of the most important parts of our work now, is to get enough donations to keep the project sustainable. We use our resources on payouts for all contributors once they reach a certain threshold. In addition to that, we want to make sure that over time, the project has some left-over resources so that we can save when times are hard. We also want to give back to our maintainers working hard to make the project great in terms of merch (aka swag). This year we will try something new, which is so have dedicated sections where companies/individuals that contribute a significant amount will have a place to showcase their product/thing. 
+I hope that you found this list useful and that you are **excited for 2026**, we are! One of the most important parts of our work now, is to **get enough donations** to keep the project sustainable. We use our resources on **payouts for all contributors** once they reach a certain threshold. In addition to that, we want to make sure that over time, the project has **some left-over resources** so that we can save when times are hard. We also want to give back to our **maintainers working hard** to make the project great in terms of **merch (aka swag)**.
+
+This year we will try something new, which is to have **dedicated sections** where **companies/individuals that contribute a significant amount** will have a place to **showcase their product/thing**.
 
-If you are interested in contributing to the organization either finanically or whatnot, please reach out to us! 💙
+If you are interested in contributing to the organization either **financially** or otherwise, please **reach out to us!** 💙
 
-~ webpack TSC
+~ webpack TSC