Rslib: a library build tool on top of Rsbuild and Rspack

Where Rslib sits inside the Rstack toolchain

Rslib is a library development tool built on Rsbuild, and Rsbuild is the build tool layer over Rspack, the bundler. The README places Rslib in Rstack, a JavaScript toolchain the project describes as unified and aimed at developers and agents, and lists the members: Rspack as the bundler, Rsbuild as the build tool, Rslib as the library development tool, Rspress as the static site generator, Rsdoctor as the build analyzer, Rstest as the testing framework and Rslint as the linter.

That placement explains the design. A library author has a different job from an application author: the output has to be consumable by other build tools, the formats matter more than the dev server, and the testing story has to work against the built artefacts rather than against source. Rslib packages the pieces of Rstack that apply to that job, and the README says it provides tool integrations and practices for building, debugging, documentation and testing across the whole of library development.

The project is MIT licensed, written in TypeScript, published on npm as @rslib/core, and hosted at rslib.rs. The last push to the repository was on 2026-10-15, and the recent releases are v1.0.1 on 2026-09-15, v1.0.2 on 2026-09-23 and v1.0.3 on 2026-09-29.

Zero configuration defaults that you can still extend

The first feature the README lists is ease of configuration: out-of-the-box tooling that lets a developer build a library with zero configuration, plus a set of semantic build configurations that can be extended as project needs grow.

The word semantic is doing real work there. Instead of describing a bundler pipeline, Rslib describes what the artefact is, and the tool decides which bundler options that implies. A project that needs something the defaults do not cover changes the semantic configuration rather than dropping down to raw Rspack options, and that is what keeps the configuration readable as a project grows.

The performance story follows from the layering. Rslib is powered by Rspack, and it integrates Rust based tools from the community, with SWC for the JavaScript and TypeScript transform and Lightning CSS for CSS handling. The README frames both as first class parts of the build rather than plugins bolted on afterwards.

The practical consequence for a reviewer is that an Rslib build is an Rspack build, with the same plugin and loader ecosystem, and a project that outgrows the semantic configuration can move down a level without changing tools.

Outputs shaped by how libraries are actually published

The second feature is output configuration for different runtimes, distribution methods and downstream build tools. Libraries are consumed in genuinely different ways, and the README treats that as the central problem rather than an edge case.

The examples directory shows the range concretely. There are examples for a plain React component bundle, a React component UMD build, Vue component bundles in both bundled and bundleless forms, a Solid component bundle, a Preact component bundle with bundling disabled, a module federation example, and an express plugin example. Bundled versus bundleless is the difference that bites people most often: a bundled component ships its dependencies inside, while a bundleless one leaves them to the consumer's bundler, and the two are not interchangeable in a published package.

Because these are all examples in the same repository, a team can read the difference between the configurations rather than infer it. The bundler behind them, Rspack, is also the bundler most downstream consumers use, which reduces the chance of a format that only works with one build tool.

Plugin compatibility with Rsbuild, Rspack and webpack

The third feature is the plugin ecosystem, and the README is specific about which kinds are accepted: Rsbuild plugins, Rspack plugins and webpack plugins. That last one is the interesting inclusion, because it means a project migrating from webpack does not have to rewrite its plugin stack to use Rslib.

The practical difference is where the configuration lives. A webpack plugin usually expects webpack's own configuration shape and hooks. Accepting them does not mean Rslib reproduces webpack's runtime semantics, but it means the parts of a plugin that do not depend on webpack internals can be reused, and the README presents this as continuing familiar development workflows rather than as a compatibility promise.

The tooling around the build is part of the same argument. Rsdoctor analyses builds and Rstest runs tests, and the repository's own scripts invoke Rstest, so a library project can adopt the toolchain one piece at a time instead of switching everything at once.

Component libraries without a framework commitment

Rslib is described as framework agnostic and decoupled from frontend UI frameworks, with support for React, Vue, Svelte, Solid and others through plugins. The examples back that up, since the repository carries component bundle examples for React, Vue, Solid and Preact.

For a team that publishes one component library for several frameworks, the point is consistency: the same build configuration shape, the same output settings, the same debugging and testing workflow, with the framework differences isolated in a plugin rather than in the build file. That is a real saving compared with maintaining a separate bundler configuration per framework.

For a team that publishes for exactly one framework, the same feature is mostly neutral, and the decision comes down to whether the defaults match what you would have configured by hand.

The monorepo scripts and the test layers

The repository is a pnpm workspace, and its root package.json shows how a library project using the toolchain is expected to be laid out. The scripts are worth reading because they show the intended workflow:

"build": "pnpm --filter \"./packages/*\" run build",
"build:examples": "pnpm --filter \"@examples/*\" run build",
"check": "rs check --type-check",
"lint": "rs lint --type-check",
"test": "pnpm run test:unit && pnpm run test:integration && pnpm run test:e2e",
"test:integration": "rstest --project integration",
"test:unit": "rstest --project unit*",

There are three test layers, and the split is the point. Unit tests run in one project, integration tests in another, and end to end tests build the examples first and then run from the tests directory. A library tool that is itself a build tool needs to test the artefacts it produces, not only the source, and the examples are the fixtures for that.

The same manifest pins the toolchain the project expects:

"packageManager": "[email protected]",
"engines": {
  "node": "^20.19.0 || >=22.12.0",
  "pnpm": ">=12.11.2"
}

Node 20.19.0 or newer is required, and the workspace uses pnpm with a catalog for shared dependency versions, which is why the devDependencies list catalog: entries rather than fixed versions. The repository also carries AGENTS.md, a .rstack/ directory and an rstest.config.ts, and the examples build with the same scripts a user would run.

Where Rslib does not fit, and what to check before adopting it

The clearest case against Rslib is a project with one exotic output requirement. The semantic configuration covers the common shapes, and a package that needs something unusual, a very specific bundler option for one target, ends up fighting the abstraction rather than describing its intent. At that point a direct Rspack configuration is more honest about what is happening.

The second case is a build that is not a library. Rslib is for libraries and component libraries, with tooling integrations for building, debugging, documentation and testing in that context. An application build belongs to Rsbuild, and reaching for Rslib there adds a layer that solves a problem you do not have.

The third limitation is version 1.0 and the documentation split. The README links separate documentation for Rslib v1 at rslib.rs and Rslib v0 at v0.rslib.rs, which tells you the v0 line is still documented and therefore still in circulation somewhere. A project that upgrades across that boundary has to read the migration notes, and the README does not summarise them.

What to verify first is the toolchain, because it is the constraint most likely to block a team. The engines field asks for Node ^20.19.0 or 22.12.0 and newer, pnpm 12.11.2 or newer, and the repository pins a pnpm workspace with a dependency catalog. If your CI image is on an older Node, that is a migration of its own before Rslib is even installed.

Editorial conclusion

Rslib fits a team publishing a library to npm or a component library to a registry, especially one already using Rsbuild or Rspack, since the plugin and configuration vocabulary carries over. It does not fit a project that needs one exotic output format the semantic configuration does not cover, where a direct Rspack config is clearer. Check first that your Node version satisfies the engines field, which asks for 20.19.0 or newer.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. web-infra-dev/rslib on GitHub