Rsdoctor: a build analyzer that reads Rspack internals, not just the output

Written for Rspack, and only for Rspack

The scope statement is the first thing to understand about this project. Rsdoctor is a build analyzer tailored for projects built with Rspack, and the README is unusually blunt about what happens to everyone else: webpack projects should continue using Rsdoctor 1.x or move to Rspack, with a migration guide linked for the details.

That is a real constraint rather than marketing framing. The 2.x line reads Rspack's own compilation hooks to build its report, and those hooks do not exist in webpack. The README is candid that its implementation refers to earlier projects, crediting bundle-stats, webpack-bundle-analyzer, Statoscope and vite-plugin-inspect, and it says the treemap visualization follows the classic webpack-bundle-analyzer layout. So the artifact analysis feels familiar because it is a successor to those tools, while the timing and dependency analysis is where Rspack-specific work shows up.

For a team running Rspack through Rsbuild, this is the analyzer that understands what your config is doing. For a team on webpack, the honest answer is that you are looking at the wrong major version and the project would rather you knew that now.

What the three analysis categories actually cover

The feature list divides into build artifact analysis, build-time analysis, and build rules, and the distinction matters more than the marketing label of intelligent analyzer suggests.

Build artifact support covers resource lists and module dependencies, which is the familiar territory: what ended up in the bundle and how the modules connect. Build-time analysis covers Loader, Plugin and Resolver build process analysis, which is where Rspack pays off, since these are the hooks Rsdoctor instruments to attribute compilation time to individual build steps. Build rules are the scanning side, covering duplicate package detection and an ES Version Check.

Compilation visualization sits on top of all three, presenting compilation behavior and time consumption so a slow build can be attributed rather than merely observed. The README also documents custom rules: beyond the built-in scan rules, you can add your own component scan rules against Rsdoctor's build data. That extension point is the one to look at first if your team has house rules about bundle composition, because it means the analyzer can become your lint layer for output rather than a one-off report.

The repository structure backs this up. Under `packages/` the monorepo holds the core and the framework plugins, and the `examples/` directory ships eight runnable cases covering Rsbuild, Rspack child compilers, Rspack layers and Rspress, which tells you the harder configuration shapes are the ones with fixtures.

Adding it to a project and reading the report

The README delegates the actual setup to a Quick Start page at rsdoctor.rs and keeps no command block of its own, which is an unusual choice for a project of this size and worth knowing before you start. What the repository root does show is the toolchain the project is developed with, and it is strict about it. The root `package.json` pins the package manager and requires a specific floor:

  "packageManager": "[email protected]",
  "engines": {
    "node": ">=22.18.0",
    "pnpm": ">=11.0.0"
  }

The same file also spells out how the repo builds itself, running each workspace package's build while leaving the documentation package out of the reactor:

  "build": "pnpm --workspace-concurrency=10 --filter \"./packages/*\" --filter \"!./packages/document\" --filter \"./scripts/*\" run build",
  "format": "rs fmt",
  "lint": "rs lint --type-check"

Those are contributor commands rather than consumer commands. If you are adding Rsdoctor to an application, the versions that matter are your Rspack version and the Rsdoctor major you pick, and the Quick Start page covers the rest.

One detail that tells you the reporting is designed to be consumed by other tools: the repo carries an `e2e/` directory, an `AGENTS.md`, and a `skills-lock.json`, which is consistent with the Rstack project's stated aim of being a toolchain for developers and agents rather than only for humans.

Version 2 is still in pre-release, and the difference matters

The release list is dense around the 2.0 line: v2.0.0-rc.0 on 2026-09-18, v2.0.0-beta.4 and v2.0.0-beta.3 both on 2026-09-17. Four beta or release-candidate builds in two days, with the last push on 2026-09-20, is a project moving fast toward a major it has not yet shipped.

If you are evaluating Rsdoctor now, that means 1.x and 2.x are not feature-equivalent and the migration guide exists precisely because the Rspack-only scope arrived with the major bump. Pinning matters more than usual here, because a plugin that reads compiler internals can break on a patch bump in either the analyzer or the bundler.

The last push date of 2026-09-20 sits comfortably inside the project's active period, and the open v2.0.0 pre-release state is the main upgrade risk to plan for rather than a sign of neglect. Read the migration guide before you touch an existing 1.x installation, and test the report against a known-good build so a silent change in attribution does not look like a performance regression.

Where it fits against bundle-stats, Statoscope and vite-plugin-inspect

The README's credits section is the most useful comparison in the project, because it names what Rsdoctor took from each predecessor and by implication where it is meant to be better.

Against webpack-bundle-analyzer it is explicit that Rsdoctor is inspired in build artifact analysis and reuses the classic treemap. So if your current question is only which chunk is too big, Rsdoctor will not surprise you and the incumbent does that job. Against bundle-stats and Statoscope it claims inspiration in build analysis more broadly, without claiming to replace their artifact tooling. Against vite-plugin-inspect it credits inspiration for build process analysis, which is the same territory where Rsdoctor adds Rspack hooks.

The practical difference is coverage of time rather than coverage of bytes. Artifact analyzers answer what shipped. Rsdoctor also answers which loader, plugin or resolver consumed the build, which only works when the bundler exposes that, which is why the Rspack requirement is the price.

There is one honest limitation to weigh: the README's own contribution invitation, the community Discord, and the docs site are all run by the same Rstack team that maintains Rspack and Rsbuild. There is no independent governance or compatibility matrix published on the README page, so if you need assurance about Rspack version combinations you will be reading their docs rather than a third party test matrix.

Editorial conclusion

Rsdoctor earns its place on a team that has already committed to Rspack, because its build-time analysis of loaders, plugins and resolvers has no equivalent in the tools it credits as its inspirations. It is the wrong choice for a webpack project on the current version, where the project explicitly says to keep using 1.x or migrate the bundler first, and it is also the wrong choice if you want one analyzer that covers several bundlers. Version 2.0.0 is still settling, with v2.0.0-rc.0 published 2026-09-18 after four beta builds in the preceding days, so pin an exact version and read the migration guide at rsdoctor.rs before upgrading. Start by adding `@rsdoctor/rspack-plugin` to one Rspack config and reading the report it opens.

Frequently asked questions

Official sources

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