Rspack 2.2: A Rust-based webpack replacement that keeps the plugin ecosystem

What Rspack solves and who it targets

Rspack is a bundler written in Rust that aims to replace webpack while keeping the same API. The problem it addresses is build performance. Webpack, written in JavaScript, becomes slow on large projects, especially during startup and hot module replacement. Rspack's README claims fast startup and lightning HMR through a built-in incremental compilation mechanism. The target user is a webpack user who wants faster builds without rewriting the project or abandoning the webpack plugin ecosystem. It is also framework agnostic, so it works with React, Vue, or anything else. The README positions it as part of the Rstack toolchain, which includes Rsbuild, Rspress, and others. If you are a webpack user hitting build time limits, Rspack is directly aimed at you.

How Rspack works: Rust core with NAPI bridge

Rspack's core is written in Rust. The README credits SWC for code parsing, transformation, and minification, and esbuild for inspiring the concurrent architecture. It uses NAPI-RS to bridge Rust and JavaScript, which is how it exposes a Node.js API that mimics webpack. The bundling process runs in Rust, while loaders and plugins from the webpack ecosystem run in JavaScript. The incremental compilation mechanism is built in, which speeds up HMR. The README also mentions rspack_sources, a Rust port of webpack-sources, indicating that they reimplemented lower-level webpack utilities in Rust. The architecture is not a fork of webpack; it is a separate implementation that mirrors the API. This means that the data flow is similar to webpack: you feed a config, it resolves modules, applies loaders, runs plugins, and outputs bundles. But the heavy lifting happens in Rust, which is why it can be faster. The documentation at rspack.rs provides more detail, but the README alone shows a deliberate design to keep the webpack interface while moving the engine.

Getting started: commands and configuration

The README points to a Quick start guide at rspack.rs/guide/start/quick-start. It also offers a StackBlitz example for immediate experimentation. The primary package is @rspack/core on npm. To install, you would typically run npm install @rspack/core. The configuration is webpack-like: you create a rspack.config.js file that exports an object with entry, output, and module rules. For example, a minimal config might look like: const rspack = require('@rspack/core'); module.exports = { entry: './src/index.js', output: { path: __dirname + '/dist', filename: 'bundle.js' } };. You then run the rspack CLI, which is available via npx rspack. For development, there is a separate package rspack-dev-server. The README lists rspack-dev-server as a dev server for Rspack. The exact commands are not in the README, but the pattern matches webpack. You can also use Rsbuild, which is a higher-level build tool that wraps Rspack. The StackBlitz link suggests that you can fork a template and start without local setup. The key point is that if you know webpack, you already know the shape of Rspack config.

Webpack compatibility: what it means and what it does not

Rspack claims to be compatible with webpack plugins and loaders. This is a strong claim. The README says it modernizes the webpack API to enable seamless replacement. But compatibility is not absolute. Plugins that rely on webpack's internal hooks or tap into undocumented APIs may not work. Loaders that use webpack-specific utilities might also fail. The README credits webpack and its community for inspiration, but it does not guarantee that every plugin works. In practice, you need to test each plugin. The project maintains a compatibility list in its documentation, but that is not in the README. The claim of seamless replacement is marketing language. The reality is that Rspack implements a large subset of the webpack API, but not all of it. For example, Module Federation is supported, which is a complex feature. But other advanced features might lag. The README also mentions production optimization like tree shaking and minification, which are built in. However, the exact behavior may differ from webpack's defaults. You should not assume that a webpack config will work without modification.

Performance expectations and benchmarks

The README does not provide specific benchmark numbers. It links to a build-tools-performance repository and an ecosystem benchmark site. Those are the places to look for comparisons. The claim is that Rspack is fast, based on Rust. But fast is relative. The README says it brings lightning-fast build speeds, but that is a promotional phrase. The CodSpeed link suggests they track performance over time. The ecosystem benchmark at ecosystem-benchmark.rspack.rs shows trends. Without running the benchmarks myself, I cannot confirm any numbers. The point is that you should not take the README's speed claims at face value. You need to measure against your own project. The build-tools-performance repository likely includes comparisons with webpack, Vite, and others. That is the right source for data. Rspack's architecture, with a Rust core and concurrent processing, should be faster than webpack in many cases, but the actual gain depends on your project size and configuration. The incremental compilation mechanism is designed to speed up HMR, which is often the biggest pain point in development.

Limitations and when Rspack is the wrong tool

The most obvious limitation is that Rspack is not webpack. Even with high compatibility, there will be edge cases. If you use a webpack plugin that is not ported or that relies on internal hooks, it will break. The README lists Module Federation as a first-class feature, but other advanced features may be missing. Another limitation is the maturity of the ecosystem. Rspack is part of Rstack, which is a newer toolchain. The documentation has separate versions for 0.x, 1.x, and 2.x, which suggests rapid change and potential breaking changes between major versions. The recent releases v2.2.1 and v2.2.0 are close together, indicating active development. This also means that the API might shift. If you need a stable, long-term bundler, webpack might be safer. Another case where Rspack is the wrong tool is if you have a simple project that does not need the webpack ecosystem. A tool like esbuild or Vite might be simpler. Rspack is designed for webpack users. If you are starting from scratch with no webpack legacy, you might not need the compatibility layer.

Alternatives: webpack, esbuild, and Vite

The direct alternative is webpack itself. Webpack is mature, has a massive ecosystem, and is stable. The difference is that webpack is written in JavaScript, so it is slower. Rspack offers a Rust core with the same API. Another alternative is esbuild, which is also written in Rust (actually Go, but the README credits esbuild's concurrent architecture). esbuild is extremely fast but has a different API and does not support webpack plugins. Vite is another option, which uses esbuild for dependencies and Rollup for production builds. Vite has a plugin system that is different from webpack. The key difference is that Rspack aims to be a drop-in replacement for webpack, while Vite and esbuild require you to change your configuration and plugins. If you value the webpack ecosystem, Rspack is the only fast alternative that keeps it. If you are willing to change, esbuild or Vite might be simpler and faster for greenfield projects. The README also mentions Rsbuild, which is a build tool that wraps Rspack, providing a higher-level interface. That is another option, but it is not a direct alternative to Rspack itself.

Maintenance, upgrades, and license

Rspack is licensed under MIT, which is permissive. The README does not mention any usage restrictions. The project is actively maintained, with releases v2.2.1 and v2.2.0 in August 2026. The last push is the same day as the latest release, so development is ongoing. The documentation is split by major version, with separate docs for 0.x, 1.x, and 2.x. This implies that upgrading between major versions might require changes. The project is part of Rstack, which includes Rsbuild, Rslib, and others. This suggests a coordinated ecosystem, but also that Rspack is not a standalone project. For maintenance cost, you should expect to update frequently. The README does not provide a migration guide, but the versioned docs suggest that each major version has its own documentation. You should check the changelog for breaking changes. The license is MIT, so you can use it in commercial projects without concern. The contribution guide and code of conduct are present, indicating a community-driven project. The ByteDance Open Source Code of Conduct is mentioned, which is a specific governance model. Overall, the maintenance cost is manageable if you stay up to date with releases.

Editorial conclusion

Adopt Rspack if you run a webpack project that has outgrown build speed or HMR performance, and if you rely on the webpack ecosystem of plugins and loaders. Do not adopt it if you need a stable API for mission-critical builds without time to test plugin compatibility, or if your project depends on niche webpack internals that may not be ported. Before switching, verify that every loader and plugin in your config works with Rspack 2.2.1, especially Module Federation setups, and benchmark your own build with the official build-tools-performance suite. The project is under active development with frequent releases, so pin your version and track the changelog. Rspack is not a drop-in guarantee; it is a fast alternative that you must validate against your own codebase.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes