Rspack: a Rust bundler that keeps the webpack API

The webpack config you already have is the migration path

Rspack targets a narrow, well-defined problem: teams with a working webpack setup who want faster builds without rewriting configuration. The README calls it "a fast Rust-based bundler for the web" that "modernizes the webpack API to enable seamless replacement of webpack". That sentence is the whole pitch. Loaders and plugins written for webpack are meant to keep working, and the config shape stays familiar, so the migration is closer to a dependency swap than a rebuild.

The audience follows from that. If your build is a few hundred lines of webpack config with a handful of loaders, Rspack is aimed at you. If you have never written a webpack config, the compatibility promise buys you nothing, and the extra surface area of a webpack-shaped API is a cost rather than a benefit. The README lists six features: fast startup, incremental HMR, webpack compatibility, Module Federation, production optimization such as tree shaking and minification, and framework agnosticism. Only one of those is about speed. The rest are about fitting into an ecosystem that already exists.

Rust core, JavaScript config: where the two halves meet

The repository is a Cargo workspace at the root and a pnpm workspace underneath it. Cargo.toml declares members as "crates/*", "xtask/benchmark" and "xtask", with the workspace version at 0.102.4 while package.json carries version 2.2.4. Those two numbers move independently, which tells you the split directly: the crates hold the compiler, and the npm packages hold the JavaScript-facing API.

The README credits SWC for parsing, transformation and minification, and says esbuild inspired "the concurrent architecture of Rspack". NAPI-RS is credited as the binding layer, which is how the Rust core is called from Node. So the data flow is: your webpack-shaped config is read on the JavaScript side, the work is handed to the Rust core through native bindings, and the output is emitted back to the Node process. There is also a WebAssembly path. The build scripts include build:cli:dev:wasm, build:cli:release:wasm and build:cli:release:browser, so the core can be compiled for environments without native bindings.

The repository layout backs this up. crates/ holds the Rust side, packages/ holds the npm packages, npm/ holds the published package sources, and tests/ holds the test suites. There is a dedicated crates/rspack_sources, described in the README as a Rust port of webpack-sources. Porting that package rather than depending on the JavaScript original is a deliberate choice: it removes a JavaScript dependency from the hot path of source map generation.

Installing Rspack and building a first bundle

The README points to the Quick start page at rspack.rs/guide/start/quick-start rather than inlining steps, and it links a StackBlitz example. There is also a create-rspack package referenced in the root build scripts, which is the scaffolding route. The npm package is @rspack/core, and the CLI lives in @rspack/cli.

The root package.json shows the project's own setup script, which is how the maintainers bootstrap the repository rather than how you add Rspack to an application:

pnpm install && pnpm run build:cli:dev

For an application, the packages to depend on are the ones named in the build scripts: @rspack/core and @rspack/cli. The repository's examples/ directory contains basic/, react/ and vanilla/ projects, and examples/README.md describes them, so those are the reference setups to read alongside the Quick start page.

For iterative work, the README links rspack-dev-server as the dev server for Rspack. The root package.json also defines a dev script, but it runs the CLI package's own development task, which is for working on Rspack itself rather than on your application. Do not confuse the two when you are setting up a project.

If you are migrating rather than starting fresh, the practical first step is to leave your existing webpack config in place and change only the tool that reads it. Anything that fails at that point is a compatibility gap, and it will fail loudly rather than silently.

The compatibility claim is the part to test, not the part to trust

Webpack compatibility is the reason to pick Rspack, and it is also the least verifiable claim from outside. The README says Rspack is "Compatible with plugins and loaders in the webpack ecosystem", but it does not enumerate which ones, and it does not describe a conformance suite in the README itself. The tests/ directory exists, and the repository keeps separate documentation trees for 2.x, 1.x and 0.x at rspack.rs, v1.rspack.rs and v0.rspack.rs. Three live doc versions is a signal about how much the API has moved between major versions.

That version history matters for a migration. A plugin that hooks into webpack internals at a level Rspack has reimplemented is where breakage concentrates, and the deeper the hook, the more likely it is to depend on behaviour rather than on the documented interface. Loaders are usually safer because they operate on a narrower contract: file contents in, transformed contents out. Plugins that reach into the compiler's hook lifecycle are where you should spend your testing time.

The honest framing is that Rspack is a reimplementation of a large API, not a wrapper around webpack. Anything a wrapper would inherit for free, a reimplementation has to rebuild. The README's phrasing, "modernizes the webpack API", is doing real work: it is an admission that the API is not identical, only close.

Rspack against Vite, esbuild and webpack itself

The alternatives split into two groups. Vite and esbuild are different tools with different config models; webpack is the same config model with a different engine.

Against webpack, the difference is the implementation language and the incremental compilation design. Webpack is JavaScript; Rspack is Rust with a JavaScript API. The README claims "Fast Startup" and "Lightning HMR" with "a built-in incremental compilation mechanism", and points to an external build-tools-performance repository and an ecosystem-benchmark site for comparisons. Those numbers live outside this repository, so treat them as claims to check on your own codebase rather than as settled facts. The migration cost, though, is genuinely low in the common case, and that is the strongest argument for Rspack over any other option here.

Against esbuild, the difference is scope. esbuild is a bundler and transformer with its own plugin API, not a webpack-compatible one. Adopting esbuild means rewriting your config and re-evaluating your plugin set. Rspack's whole reason to exist is to avoid that rewrite. If your webpack config is small and your plugin list is short, esbuild's smaller surface may be the better trade. If your config is large, it will not be.

Against Vite, the difference is the development model. Vite serves modules natively in development and bundles for production; Rspack bundles in both. That means Vite's dev server behaviour and Rspack's dev server behaviour are not the same thing, and configs do not transfer between them. Choosing between the two is closer to choosing a build philosophy than to choosing a faster engine.

There is also a family question. Rsbuild is listed in the README as the "Build tool" in Rstack, with Rspack as the "Bundler" underneath it. If you want sensible defaults rather than a webpack-shaped config, Rsbuild is the layer above. Rslib covers library development, Rspress static sites, Rsdoctor build analysis, Rstest testing and Rslint linting. Picking Rspack directly means you have chosen to own the config.

Licence and the cost of keeping up with a 2.x line

The repository is MIT licensed, and LICENSE sits at the root. There is also a THIRD-PARTY-LICENSE file, which is what you would expect from a project that links a large number of Rust crates. Cargo.toml lists a long workspace.dependencies block, and deny.toml at the root suggests dependency licence and advisory checks are part of the project's own workflow. If your organisation runs licence scans, THIRD-PARTY-LICENSE is the file to feed it, and the MIT grant on Rspack's own code does not automatically describe every crate in the tree.

Upgrade cost is the other ongoing expense. The README maintains three documentation sites, one per major version, and the latest releases at the time of writing are v2.2.1, v2.2.0 and v2.2.0-rc.0, with the last push to the repository on 2026-08-27. A project shipping release candidates alongside stable releases on consecutive days is moving quickly. For a bundler that is a good sign for fixes and a bad sign for config stability, and the three-version doc split is the evidence.

There is no documented rollback path in the README. If you migrate a large webpack config and hit a blocker, the README does not describe how to revert or how to run Rspack and webpack side by side in one repository. That is a gap worth planning around before you delete your webpack dependency.

Who should and should not reach for Rspack

Reach for Rspack if you have a webpack config that you understand and maintain, if your plugin list is mostly loaders and well-behaved plugins, and if build time is a real constraint on your team. The migration story is the product, and it is a good story in that case.

Do not reach for it if you are starting a new project with no webpack history. You would be adopting a webpack-shaped API without the webpack ecosystem knowledge that makes it useful, and Rsbuild in the same family gives you the bundler with defaults instead of a config file. Do not reach for it either if your build depends on a plugin that hooks deeply into webpack's compiler internals; that is exactly the surface a reimplementation is most likely to diverge on, and the README does not promise otherwise.

What to verify first is concrete: run your existing webpack config through Rspack unchanged and count the failures. Then check the Rspack 2.x documentation for each plugin you cannot drop. Then decide whether the speed is worth the upgrade cadence implied by three parallel doc versions and release candidates landing next to stable releases.

Editorial conclusion

Adopt Rspack if you already maintain a webpack config and want the same loader and plugin model without rewriting your build, and if you can run the webpack compatibility tests that matter to your project. Do not adopt it as a first bundler for a new app: Rsbuild is the higher-level build tool in the same Rstack family, and Vite or esbuild give you a different, smaller config surface. Before committing, check the Rspack 2.x documentation for the exact webpack plugins and loaders you depend on, confirm the version your package manager resolves for @rspack/core, and read THIRD-PARTY-LICENSE alongside the MIT LICENSE in the repository root, because the Rust crates it links against may carry their own terms.

Frequently asked questions

Official sources

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