Rslib
An Rsbuild-powered build tool for creating JavaScript and TypeScript libraries with zero-config defaults and flexible multi-format output.
Repository Health
Technical Analysis
Rslib is a library development tool built on top of Rsbuild, giving JavaScript and TypeScript library authors a purpose-built alternative to hand-rolling bundler configs with webpack, Rollup, or generic build scripts. It ships opinionated defaults for the parts of library packaging that are easy to get wrong — ESM/CJS/UMD output formats, type declaration (.d.ts) generation, CSS extraction, and package.json export validation — while still exposing the full Rsbuild/Rspack plugin surface for teams that need to customize.
Because it’s powered by Rspack (a Rust-based bundler with webpack-compatible APIs) and integrates tools like SWC and Lightning CSS, Rslib targets both build performance and compatibility with the existing webpack/Rspack plugin ecosystem. It’s framework-agnostic, so component libraries for React, Vue, Svelte, or Solid can all use the same rslib.config.ts shape and CLI (rslib build, rslib --watch) rather than each maintaining a bespoke bundler pipeline.
What You Get
- Zero-config library builds that produce ESM, CJS, and UMD output from a single
rslib.config.ts, with per-environment overrides when defaults aren’t enough - Built-in TypeScript declaration (
.d.ts) generation via the companionrsbuild-plugin-dtspackage, including bundled type rollups - A CLI (
rslib,rslib --watch,rslib inspect) plus a fully programmatic API (createRslib,build,defineConfig,loadConfig) for scripting builds - Reuse of the entire Rsbuild/Rspack/webpack plugin ecosystem, so existing bundler plugins keep working instead of requiring an Rslib-specific rewrite
- CSS extraction and asset handling tuned for library output (as opposed to application bundling assumptions)
- Module Federation (
mf) build target support for teams shipping federated library modules
Common Use Cases
- Publishing a UI component library that needs to ship ESM and CJS builds simultaneously for compatibility with both modern bundlers and legacy Node consumers
- Migrating an internal package off a hand-maintained Rollup or tsup config onto a maintained tool with first-class type-declaration generation
- Building framework-agnostic packages (utility libraries, SDKs, design-system primitives) that need consistent build tooling across many packages in a monorepo
- Replacing ad-hoc webpack library configs with a Rspack-backed pipeline to cut build times without rewriting existing plugin usage
Under The Hood
Architecture
Execution starts at bin/rslib.js, which enables Node’s compile cache and lazily imports runCLI from the built dist/index.js. runCLI (src/cli/index.ts) sets the log level from argv, prints the greeting banner, and delegates to setupCommands (src/cli/commands.ts), which wires a cac-based CLI with build, inspect, and mf-dev commands. Each command path funnels into createRslib (src/createRslib.ts), which loads env vars, resolves the user’s RslibConfig, and exposes build, inspectConfig, and startMFDevServer closures. The real transformation work happens in src/config.ts (~2000 lines), whose composeRsbuildEnvironments maps each declared library/format pair onto an independent Rsbuild EnvironmentConfig, layering in CSS handling (src/css/), asset rules (src/asset/), executable packaging (src/exe/), WASM composition (src/wasm/), and shim plugins (src/plugins/) before handing the composed config to @rsbuild/core’s own createRsbuild/build/startDevServer lifecycle — Rslib itself never touches Rspack directly, it only assembles Rsbuild configuration.
Tech Stack
TypeScript throughout, published as pure ESM, targeting Node ^20.19.0 || >=22.12.0. Built directly on @rsbuild/core (the Rsbuild build tool, itself Rspack-based) and the workspace-local rsbuild-plugin-dts for type declarations; cac handles CLI argument parsing, get-tsconfig/typescript support tsconfig-aware path resolution, tinyglobby and path-serializer handle file matching, and fs-extra/memfs support config and virtual-fs operations in tests. The monorepo itself is a pnpm workspace (pnpm@11.24.0) using a catalog: dependency-version scheme, built and bootstrapped via its own sibling tools (Rslib builds Rslib) and rstack.config.ts.
Code Quality
Testing is layered: unit tests live under packages/core/tests (27 files covering config composition, CLI behavior, tsconfig resolution, executable packaging, and syntax handling, using snapshot assertions), while root-level tests/ holds integration and Playwright-driven end-to-end suites (over 1,200 files including fixtures), all run through the project’s own @rstest/core test runner. Error handling favors explicit thrown Errors with descriptive messages (dozens of call sites) rather than silent fallbacks. Linting and formatting are enforced through the team’s own rstack CLI (rs lint --type-check, rs fmt) and dedicated GitHub Actions workflows for lint, unit/integration/e2e tests, and benchmarks run on every change.
API Design
The public surface is deliberately small: defineConfig for authoring rslib.config.ts, loadConfig/loadEnv for programmatic config resolution, createRslib/build for scripted builds, and mergeRslibConfig for composing configs across shared presets — all re-exported from a single src/index.ts entry point alongside re-exported Rsbuild/Rspack types. A minimal library config ({ lib: [{}] }) is enough to get a working multi-format build, with most further customization expressed as small, additive per-format overrides rather than a wholesale config rewrite, which keeps the everyday config surface concise even though the full underlying Rsbuild/Rspack config remains reachable for advanced cases.
Used by 2 apps in this directory
NocoDB
No Code Platforms · Databases · Low Code Platforms
Turn any SQL database into a collaborative no-code spreadsheet with automatic REST APIs and real-time views.
Webiny JS
Ecommerce · Blogging · CMS
Open-source, self-hosted CMS on AWS serverless — a TypeScript framework you extend with code, not a product you configure through a UI.