Roadmap 2026 (2026-02-04)

Hello from the webpack Technical Steering Committee member Even!

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 - Support for CSS Modules without the need for plugins

There is currently an experimental.css 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.

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 to stay updated and contribute ideas.

webpack#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), along with adding missing tests and completing the CommonJS wrapper functionality.

You can also join the discussion about universal target to share your ideas or follow updates on cross-runtime compatibility.

Support for building TypeScript without loaders

Recently, in version 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). 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 - 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). 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.

You can follow the idea and its progress in webpack#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 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).

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 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 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 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, project or similar.

If you are interested in contributing to the organization either financially or otherwise, please reach out to us! 💙

~ webpack TSC