Rspack: a Rust bundler wearing the webpack API

crates/ holds the engine and packages/ holds the surface you configure

Rspack is a Cargo workspace and a pnpm workspace in the same repository. Cargo.toml declares members as `crates/*` plus `xtask/benchmark` and `xtask`, with edition 2024 and resolver 2, and every entry in its workspace dependencies table is pinned with `default-features = false`. The JavaScript side lives in packages/, and the root package.json points its main field at `./packages/rspack/dist/index.js`.

So the file you edit and the binary that runs it are in different languages in different trees. The README credits the SWC project with powering Rspack's code parsing, transformation and minification, and credits esbuild for inspiring Rspack's concurrent architecture. Rust itself does the module graph and the bundling.

What the README does not give you is a split of responsibilities inside that stack. There is no list of which webpack behaviours run in Rust, which are handed to SWC, and which still fall back to JavaScript, and no option-by-option table for webpack settings Rspack accepts. For a team evaluating a replacement, that map is the thing you actually need, and it lives in the documentation site rather than in the repository.

Building from source means picking one target, and pnpm install alone gives you nothing

The root package.json is private and named monorepo, and its setup script is two steps rather than one:

pnpm install
pnpm run build:cli:dev

That second line matters. Cloning the repository does not produce a bundler, because the native binding has to be compiled before anything runs. The release scripts are cut per target, and you build one at a time:

pnpm run build:cli:release:x64
pnpm run build:cli:release:arm64
pnpm run build:cli:release:wasm
pnpm run build:cli:release:browser

The list also names linux, win, an all platforms variant and a plain release build. wasm and browser targets mean the core is expected to run outside Node as well as inside it, which the README does not follow up on.

For a contributor this is the real cost of the project. A change to a crate needs a matching build of the binding for the platform you are on, and a release build is per platform rather than one artefact that runs everywhere, so anyone verifying your fix on Linux is not testing what you tested on macOS.

Two version lines and three documentation sites

The newest releases are v2.3.0 on 2026-10-29, v2.3.0-rc.0 on 2026-10-27 and v2.3.0-beta.1 on 2026-10-22, and the last push to main was on 2026-11-02. The repository is not archived, and a run of three releases inside about a week is what the current state looks like from the tags alone.

Now the numbers. The root package.json says version 2.3.0, matching the newest tag. The Cargo workspace package says version 0.103.0. So the JavaScript distribution and the Rust crates do not share a version line, and a panic message from a crate will carry a number that means nothing to your package.json lockfile.

The documentation is versioned the same way: Rspack 2.x docs at rspack.rs, 1.x at v1.rspack.rs and 0.x at v0.rspack.rs. A search result or a teammate's link can land you on either older site, and the 0.x and 1.x docs describe older versions. Pin your version before you read the docs, or you will configure against a schema you are not running.

Webpack compatibility is one sentence, and there is no matrix behind it

The README claims compatibility with plugins and loaders from the webpack ecosystem, and the tree backs that up in small ways: crates/rspack_sources is a Rust port of webpack-sources, the library webpack itself uses for source maps, so the output format is a deliberate port rather than a reimplementation from scratch. Module Federation is called out as first class support, and the credits name @ScriptedAlchemy for creating Module Federation and for helping Rspack connect with the community.

Beyond that there is nothing to grade the claim against. The README has no compatibility matrix, no list of loaders known to break, and no count of how much of the plugin surface is implemented. A loader that reaches into webpack's internal compiler object is the failure you should expect, and nothing in the repository warns you which ones those are.

That is the practical gap between adopting Rspack for a fresh project and adopting it to replace webpack. On a new build you can choose plugins that fit. On an existing one you have an inventory of loaders and plugins nobody has tested, and the only way to find out is to run the build.

The dev loop is split across two repositories, and the fast claims live off site

HMR speed comes from a built-in incremental compilation mechanism, which is a mechanism rather than a number, and the README attaches no figure to it. The dev server itself is not in this repository. It lives at github.com/rstackjs/rspack-dev-server, and the only development entry point here is `pnpm run dev`, which delegates to `@rspack/cli`.

That division has a consequence for anyone filing a bug or bisecting a slow rebuild. Part of the loop you feel is maintained somewhere else, and a regression in HMR or in live reload may never touch a commit in this repository. The bundler and the server have separate release histories.

Performance claims follow the same pattern. The README publishes no benchmark numbers and links two places for them instead: the build-tools-performance repository for comparisons against other tools, and ecosystem-benchmark.rspack.rs for Rspack's own performance trends over time. Both are good sources and neither is readable from here, so any speed figure you quote about Rspack comes from somewhere you have to go and check.

Rstack ships seven packages and pins none of their versions

Rspack is one entry in a wider toolchain the README calls Rstack, a unified JavaScript toolchain for developers and agents. The table beside it lists Rsbuild as the build tool, Rslib for library development, Rspress as a static site generator, Rsdoctor as the build analyzer, Rstest as the testing framework, Rslint as the linter and Rstack CLI as the unified CLI, each with an npm link in a Version column.

The Version column holds an npm badge link for each package rather than a pinned number, so nothing in the README tells you which version of Rsbuild pairs with Rspack 2.3.0. Install the wrong pairing and the symptom is a bundler that does not match the tool you drive it with, and the fix lives in a separate repository's release notes.

The tree shows the same sprawl in another form: examples/ holds basic, react and vanilla smoke builds, and the repository also carries AGENTS.md, a skills-lock.json and an agent-skills project listed in the README's links. Useful for onboarding, and more moving parts than a bundler strictly needs.

Replacing webpack is the pitch, and the migration story is off the README

The pitch in one line is that Rspack modernizes the webpack API so webpack can be replaced. What follows that line in the README is a feature list: fast startup from Rust, lightning HMR, webpack compatible plugins and loaders, Module Federation, production optimization such as tree shaking and minification built in by default, and being framework agnostic.

None of that is a migration path. There is no codemod, no list of webpack options that changed behaviour, no mapping of old config keys to new ones, and no statement about what framework agnostic costs you. The three example projects are smoke tests for a greenfield build, not upgrade guides.

So the honest version of the decision is that Rspack is a bundler you adopt by editing a configuration file you already have, while verifying by hand which of its behaviours you were relying on. Teams with a small, modern config and few exotic loaders get the best of it. Teams with a decade of accumulated plugin behaviour will find the verification cost before they find the speed.

Editorial conclusion

Rspack fits teams that already have a webpack configuration and want the same config keys against a native core. It does not fit a team hoping to swap in one command: the README documents no install command, no loader compatibility table and no migration path, and the Rust crates carry a different version line from the npm packages. Verify first that the loaders and plugins your build actually uses appear in the 2.x documentation on rspack.rs, since the compatibility claim in the README is a single sentence.

Frequently asked questions

Official sources

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