Add roadmap for 2026

src/content/blog/2026-04-02-roadmap-2026.mdx

@@ -0,0 +1,160 @@
+---
+title: Roadmap 2026 (2026-02-04)
+sort: 9
+contributors:
+  - evenstensberg
+  - bjohansebas
+  - UlisesGascon
+---
+
+Hello from the webpack Technical Steering Committee member [Even](http://x.com/evenstensberg)!
+
+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**.
+
+## Here’s what we’re excited about for 2026
+
+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.
+
+Below, we’ll walk through the main areas we’re actively working on and the ideas we plan to develop throughout the year.
+
+### [webpack#14893](https://github.com/webpack/webpack/issues/14893) - Support for CSS Modules without the need for plugins
+
+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).
+
+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**.
+
+You can follow the discussion about [experimental CSS support](https://github.com/webpack/webpack/issues/14893)
+to stay updated and contribute ideas.
+
+### [webpack#6525](https://github.com/webpack/webpack/issues/6525) - A universal target to make your code compatible across runtimes
+
+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_.
+
+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_.
+
+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.
+
+### Support for building TypeScript without loaders
+
+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**.
+
+### [webpack#536](https://github.com/webpack/webpack/issues/536) - Import HTML files and use them as entry points without the need for plugins
+
+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 of webpack itself**, 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.
+
+You can follow the idea and its progress in the related issue ([#536](https://github.com/webpack/webpack/issues/536)).
+
+### Webpack Everywhere (Node, Deno, and Bun, Web)
+
+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.
+
+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.
+
+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 time, 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 development 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 (new api options, deprecations, types etc).
+
+This approach addresses long-standing problems with **incomplete, 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** that gives users a easy way to interact with webpack.
+
+### Community Outreach and Engagement
+
+Following improvements to documentation and active maintenance, 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 our outreach 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 too! One of the most important parts of our work now, is to **get enough donations** to keep the project sustainable. We use our resources to **pay 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** that we can save for when times are hard.
+
+This year we will try something new, which is to have **allocated sections** where **companies/individuals that contribute a significant amount** will have a spot to **showcase their product/project/promotion**.
+
+Thank you for the attention and for being interested in our roadmap for 2026. If you are curious about contributing to the organization either **financially** or otherwise, send us a private or public message in [Discord](https://discord.com/invite/webpack), reach us through [email](mailto:webpack-security@openjsf.org) or contact one of the [TSC members](https://github.com/webpack/webpack?tab=readme-ov-file#tsc-technical-steering-committee).
+
+~ webpack TSC 💙