Rsbuild: a Rspack-powered build tool with zero-config defaults

The gap between Rspack and a working web app

Rspack is a bundler. A bundler alone does not give you an HTML entry, a dev server, asset handling, environment variables, or a production build that behaves like the development build. Rsbuild exists to fill that gap. The README states one of its goals is "to give Rspack users out-of-the-box build capabilities so they can start web projects with zero configuration", plus a semantic configuration API that lowers the Rspack learning curve.

The audience is therefore specific: teams that have decided they want Rspack's Rust-based compilation but do not want to assemble a toolchain around it. It is also aimed at teams that already run webpack and want to keep their plugin investment, because the README claims compatibility with most webpack plugins and all Rspack plugins. If you are starting a small static site and have no opinion about bundlers, this is more machinery than you need.

What sits underneath: Rspack, SWC and Lightning CSS

The README describes Rsbuild as powered by Rspack and says it integrates "high-performance Rust-based tools from the community", naming Rspack, SWC and Lightning CSS. Those three cover the pipeline: Rspack compiles and bundles modules, SWC handles JavaScript and TypeScript transformation, Lightning CSS handles stylesheets. Rsbuild is the layer that configures and sequences them.

Two design choices stand out. First, framework agnosticism: Rsbuild is not coupled to a UI framework, and support for React, Vue, Svelte, Solid and Preact comes through plugins. The repository's examples/ directory mirrors that, with separate example projects for react, vue, svelte, solid, preact, lit and vanilla, plus node, module-federation and module-federation-v2. Second, artifact stability. The README says Rsbuild "ensures consistent artifacts in development and production builds, and automatically handles syntax downgrading and polyfill injection", and that it ships plugins for type checking and artifact syntax validation. That is a claim about output determinism, not about speed, and it is the kind of property that matters more in a large shared codebase than in a side project.

Rsbuild is also one entry in a wider set the README calls Rstack, alongside Rspack (bundler), Rslib (library development), Rspress (static site generator), Rsdoctor (build analyzer), Rstest (testing framework) and Rslint (linter). Rsbuild is the application build tool in that list, not the library or documentation tool.

Installing Rsbuild and running a first build

The README points to the Rsbuild v2 docs at rsbuild.rs for installation and usage, and the npm package is @rsbuild/core. The repository itself is a pnpm workspace, and its package.json declares engines of node >=22.18.0 and pnpm >=12.4.0 for developing the monorepo, so expect a modern Node runtime. The README does not print install commands, so the package names below are the parts the material actually fixes; confirm the CLI invocation against the v2 docs before relying on it.

The repository's own scripts show the tooling conventions. The root package.json defines a build script that runs across the workspace packages, and a test script that runs in parallel across them.

{
  "scripts": {
    "build": "pnpm --workspace-concurrency=10 --filter \"./packages/*\" --filter \"./scripts/*\" run build",
    "test": "pnpm --parallel --filter \"./packages/*\" test"
  },
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=22.18.0",
    "pnpm": ">=12.4.0"
  }
}

That block is the monorepo's own metadata, copied from the repository's package.json, and it tells you the runtime floor the project holds itself to. For consuming Rsbuild in an application, the npm package named in the README is @rsbuild/core, and framework support arrives through plugins such as @rsbuild/plugin-react. If you want a working reference instead of assembling one, the repository's examples/react and examples/vue directories are the closest thing to a starting point that ships with the source.

Where Rsbuild is the wrong choice

The README does not document a migration path from Rsbuild v1 to v2. It links two documentation sites, rsbuild.rs for v2 and v1.rsbuild.rs for v1, and stops there. If you are on v1 and the v2 config API has changed, the README will not tell you what breaks; that answer lives in the v2 docs, and you should read them before upgrading rather than after.

Framework agnosticism is also a weaker promise than it sounds. Rsbuild is not coupled to a UI framework, but each framework arrives through a plugin, and the README says support exists "with plans to support more UI frameworks from the community in the future". A framework outside the current set is a plugin you or someone else has to write. That is a real adoption cost, not a footnote.

The plugin compatibility claim deserves the same scrutiny. The README says Rsbuild is "compatible with most webpack plugins and all Rspack plugins". Most is doing visible work in that sentence. If your build depends on a webpack plugin that reaches into compiler internals, verify it against Rsbuild before you plan a migration around it. And if your project is a library rather than an application, Rsbuild is the wrong entry in the Rstack list; Rslib is the one the README names for library development.

Rsbuild vs Vite: two different bets on the dev server

Vite appears twice in this repository: once in the README's credits, which lists it among the projects Rsbuild was "derived from or inspired by", and once as the subject of a comparison people search for. The architectural difference is the interesting part. Rsbuild is a bundler-first tool: Rspack compiles the module graph, and the dev server serves from that. Vite's model is to serve native ES modules in development and only bundle for production. Those are different bets about where the cost lives, and they produce different behaviour when a project has thousands of modules or an unusual dependency graph.

The README makes no claim about Vite's performance, and neither should you take one from it. What the README does claim is artifact consistency between development and production, plus automatic syntax downgrading and polyfill injection. If matching dev and prod output is the property your team cares about, that is the argument to weigh. If you want the smallest possible dev-server startup on a fresh project, that is a different argument, and it is the one Vite's model is built around.

The same distinction applies to esbuild, which is a transformer and bundler rather than an application build tool, and to Rspack, which is the bundler Rsbuild configures. Rsbuild vs Rspack is not a rivalry: Rspack is the layer underneath, and Rsbuild is the semantic API and defaults on top of it.

Maintenance, licence and the cost of upgrading

The repository is not archived. Its last push was on 2026-08-28, the same day as the v2.2.1 release; v2.2.0 landed on 2026-08-26 and v2.2.0-rc.0 on 2026-08-24. That is a release cadence with release candidates in the open, which tells you the project ships through a pre-release channel before tagging stable.

Rsbuild is licensed under the MIT License, per the README and the LICENSE file at the repository root. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice retained. That is a statement about the licence text, not legal advice for your situation; if your organisation has a policy review for dependencies, run it.

The upgrade cost is harder to pin down from the README. Two documentation sites exist, one for v2 and one for v1, which implies the config surface changed between major versions. The repository pins [email protected] and requires Node >=22.18.0 in its own package.json, but that governs contributing to the monorepo, not consuming @rsbuild/core. Before a major upgrade, read the v2 documentation rather than inferring the diff from the README, because the README does not describe one.

Editorial conclusion

Adopt Rsbuild if you want Rspack build speed behind a small config surface, need webpack or Rspack plugin compatibility, or build several frameworks from one toolchain. Do not adopt it if you want a browser-native dev server with no bundler in development, or if your team cannot move to Node >=22.18.0 and pnpm >=12.4.0 as the repository's package.json states. Before committing, verify that the plugins you depend on list Rsbuild or Rspack support, and check the v2 docs for a migration path from v1, since the README only links the two documentation sites and describes no upgrade procedure.

Frequently asked questions

Official sources

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