Rsbuild is the build tool, Rspack is the bundler underneath it, and the repository lints itself with rs

The bundler and the build tool are different projects

The clearest thing the README does is separate the two layers. Rsbuild is a modern build tool for web applications powered by Rspack, and the toolchain table names their roles separately: Rspack is the bundler, Rsbuild is the build tool. That distinction is what the easy-to-configure feature rests on. The stated goal is to give Rspack users out-of-the-box build capability so a web project can start with zero configuration, and the reason a semantic configuration API exists at all is to reduce the Rspack learning curve. The plugin story is the other half of that positioning: Rsbuild has a lightweight plugin system with official plugins, and it is compatible with most webpack plugins and all Rspack plugins, so an existing community or in-house plugin can be reused without rewriting it.

Seven tools share one toolchain, and two doc versions stay online

The README positions Rsbuild as part of Rstack, described as a fast, unified JavaScript toolchain for developers and agents. The table gives each member a role and a package: Rspack as the bundler, Rsbuild as the build tool, Rslib as a library development tool, Rspress as a static site generator, Rsdoctor as a build analyzer, Rstest as a testing framework and Rslint as a linter. That is a coherent argument for adopting more than one of them, and it is also the boundary: nothing in this repository explains how any of the others work. The documentation is versioned too, with the current v2 docs at the main site and the v1 docs kept on a separate subdomain, which is what a project does when its configuration API has changed between major versions and old guides are still in search results.

The repository is a private pnpm workspace with a version catalog

The manifest at the root is not the package you install. It is named rsbuild-monorepo, marked private, declares the module type, and lists two workspace globs, packages and scripts, so the publishable code lives under packages while the tooling lives under scripts. Versions for the shared development dependencies are not written inline: entries for the Node types, cross-env, a spell checker word list, a heading-case helper, the rstack CLI and TypeScript all use a catalog reference, which points at a central catalog rather than a literal range. Toolchain requirements are stated twice and differently. The package manager field pins pnpm 12.9.1 exactly, while the engines field asks for Node 22.18.0 or newer and pnpm 12.6.0 or newer. There is also a .node-version file at the root and an .npmrc, so a contributor's editor and shell are pinned in three places.

The repository lints, formats and type-checks through rs

Look at the script names and the tooling choice becomes visible. Formatting is rs fmt, linting is rs lint, type checking is rs check with a type-check flag, and the prepare hook is rs hooks followed by the prebundle step. All four come from a single development dependency named rstack, which is the CLI side of the toolchain described in the README. Spelling has its own command, check-spell, which invokes cspell through pnpx, paired with a cspell configuration file and a banned-words dependency, so the repository polices its own vocabulary rather than leaving typos to review. Builds and tests both fan out across workspaces with pnpm filters, the build capping workspace concurrency at ten, and the documentation site has its own script that changes into the website directory and runs the dev server there.

Ten example projects, including two module federation setups

The examples directory holds a README and ten runnable projects, and the list is a better description of the framework support claim than the prose is. There is one per UI framework: react, vue, svelte, solid, preact, lit, and vanilla for projects with no framework at all. There is one for node, which suggests the tool is usable outside a browser bundle. And there are two module federation examples, one for the original module federation and one for version two, side by side, which is the clearest signal that module federation is treated as a supported scenario rather than an afterthought. The framework-agnostic feature claims support for React, Vue, Svelte, Solid and Preact through plugins, with plans for more from the community, and the examples directory is where that list becomes checkable.

Agent skills, a lock file and an agents directory

There is a second, less visible layer aimed at tooling rather than humans, and it runs through the whole repository. The toolchain description says it is for developers and agents, and the top level carries a directory named for agents, an AGENTS.md file, a skills lock file and a configuration file named after the toolchain itself. The links list adds a repository of agent skills for the toolchain alongside examples, a Storybook builder powered by Rsbuild, a plugin template, and a curated list of related projects. Two entries in that links list end with a full-width colon instead of an ASCII one, a small typographic tell that the section is maintained by hand. None of this changes how the build tool behaves, and all of it says the maintainers expect the toolchain to be driven by assistants as much as by terminals.

Three READMEs, a ByteDance code of conduct, and credited ancestors

The repository keeps three versions of its own README, in English, Portuguese and Simplified Chinese, linked from the header. The code of conduct is not a bespoke one: it adopts the ByteDance open source code of conduct, which fits the web-infra-dev organisation the repository belongs to. The credits section is the most informative paragraph for anyone deciding what to expect. Rsbuild is described as derived from or inspired by seven projects, and they are named: create-react-app, Vite, html-webpack-plugin, webpack-dev-middleware, connect-history-api-fallback, preload-webpack-plugin and dotenv. That list describes the lineage of a webpack-era project that changed bundlers, and it is more informative about the design than the feature list is. The licence is MIT.

Editorial conclusion

Rsbuild fits teams coming from Rspack who want working defaults without writing configuration, or coming from webpack who want to keep existing plugins, since the plugin story covers both. Three things to check before committing. The runtime floor is high and explicit: Node 22.18 or newer with pnpm 12.6 or newer, and the repository additionally pins an exact package manager version, so check your toolchain before anything else. The documentation is versioned, so confirm you are reading the v2 pages rather than the v1 ones still hosted. And decide how much of Rstack you want, because the linter, test runner, site generator and analyzer are separate packages that happen to come from the same team.

Frequently asked questions

Official sources

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