Rsdoctor

Rsdoctor is a build analyzer purpose-built for Rspack, and @rsdoctor/rspack-plugin is the plugin you drop straight into a Rspack config to get it running. Rather than guessing why a build got slower or why the output bundle grew, teams add the plugin, run their normal build, and get an interactive report that breaks the compilation down by module, chunk, loader, plugin, and resolver step.

Under the hood it wraps each Rspack compiler in its own tracked context, feeds a native module/chunk/source-map capture plugin alongside its JS-side instrumentation, and applies a small internal rule engine (duplicate-package detection, ES-target checks, custom rules) on top of the collected data. A CI-friendly “brief” mode emits a single JSON or HTML artifact instead of launching the interactive report server, and multi-compiler / child-compiler builds are automatically re-parented into one coherent session.

What You Get

• The RsdoctorRspackPlugin class — drop into your Rspack plugins array to instrument loaders, plugins, the resolver, and the module/chunk bundle graph.
• An interactive report client that opens automatically after a build, visualizing module composition, duplicate packages, per-loader/per-plugin build-time breakdowns, and bundle treemaps.
• Built-in build rules (duplicate-package detection, ES-version/target checks, and custom rule support) that can fail a build or just surface as report warnings.
• A CI-friendly “brief” output mode that emits a compact JSON or HTML report artifact instead of launching the interactive client server.
• Multi-compiler and child-compiler support so builds that spin up multiple Rspack compilers (e.g. server + client bundles) report into one coherent session.

Common Use Cases

• Diagnosing why an Rspack build got slower after a dependency or config change by comparing per-loader/per-plugin timing breakdowns.
• Hunting down duplicate or oversized dependencies bloating a production bundle via the module/chunk graph and treemap views.
• Wiring the brief JSON/HTML report into CI as a build-health artifact without needing a person to click through the interactive UI.
• Auditing loader and plugin configuration order and overlap when migrating a webpack config to Rspack.

Under The Hood

Architecture Rsdoctor’s Rspack integration centers on RsdoctorRspackPlugin (packages/core/src/rspack-plugin/plugin.ts), which wraps each Rspack compiler in a RsdoctorCompilerContext holding a per-compiler SDK and module graph; a RsdoctorSDKController coordinates multiple compiler instances (primary and “slave” SDKs) so multi-compiler and child-compiler builds are tracked as one coherent report tree, with child compilers inheriting a session lease and reporting through dedicated lifecycle hooks tied into Rspack’s afterPlugins/done/afterCompile hooks. Feature toggles (options.features.{loader,plugins,bundle,resolver}) gate a family of internal plugin classes under inner-plugins/ (loader, plugins, bundle, resolver, rules, error-reporter, summary) that each tap into the compiler to harvest one dimension of build data, alongside a native Rspack-binding plugin for lower-level module/chunk/source-map graph capture — a modular, opt-in pipeline rather than a monolithic hook.

Tech Stack The plugin package is pure TypeScript, built and tested with the team’s own Rstack tooling (rslib for library builds, rstest for the test runner, rs lint/rs fmt for linting and formatting) inside a pnpm workspace that manages shared dependency versions through a catalog: block. It depends on sibling workspace packages (@rsdoctor/shared, @rsdoctor/client) for the graph/types layer and the bundled report web client, targets @rspack/core as a peer dependency, and ships alongside a companion Rspress-based documentation site plus dedicated CI workflows for lint, Ubuntu/Windows/Node22 test matrices, and an ecosystem compatibility check.

Code Quality Rspack-plugin behavior is covered by rstest specs (plugin.test.ts, native-plugin.test.ts) exercising write-store compression heuristics and native-plugin wiring, and CI runs the suite across Ubuntu, Windows, and multiple Node versions plus a separate ecosystem-ci workflow, alongside a repo-wide lint/format pass and TypeScript’s own type checking. The plugin code itself uses class-based composition with narrow constructor-injected dependencies, explicit try/finally blocks around timed sections (time/timeEnd instrumentation), and typed, normalized options rather than loosely-typed config objects.

API Design The public surface is a single class, new RsdoctorRspackPlugin(options), mirroring the familiar “instantiate and push into plugins:[]” convention every Rspack/webpack user already knows, with behavior controlled through one options object (features, output.mode, disableClientServer, multiCompiler.enabled) rather than a scattered set of flags. It defaults to opening the generated report automatically after a build, offers a “brief” mode for CI environments that need a compact artifact instead of the interactive client, and throws an explicit, descriptive error when the plugin is misused across multiple compilers — a small, carefully guarded API surface for a tool with a lot of internal complexity.