Rspack 2 is for webpack 5-shaped builds
Rspack v2 keeps the job and much of the vocabulary of webpack 5. You provide entries, loaders, plugins, output rules, and optimization settings, then Rspack produces browser assets through a Rust core exposed to JavaScript. That familiar surface is the reason to consider it. A team can investigate a new bundling engine without first replacing every build concept or forcing application developers into a different configuration style.
The repository shows how much engineering sits behind that promise. Our measured checkout at commit 1032815 contained 22,655 files, roughly 691,633 lines of source, and 68.8 MB before dependencies. It includes Rust crates, JavaScript packages, fixtures, and monorepo workspaces. Application users install published packages, so they do not inherit that entire source tree. Contributors and teams debugging native behavior should expect a large systems project rather than a small command-line wrapper.
Webpack compatibility stops at specific flags and plugins
Rspack v2's official webpack 5 migration guide names concrete edits. Rspack CLI does not accept webpack's --progress, --color, --bail, or --output-pathinfo flags. Filesystem cache settings use a different shape, resolve.plugins is unsupported, and several familiar packages have Rspack replacements. That is a manageable checklist, but it rules out treating the change as a package-name substitution.
Plugin behavior deserves a trial against your own build. The guide says most webpack loaders and community plugins work, while also directing users to replace tools such as copy-webpack-plugin, mini-css-extract-plugin, and tsconfig-paths-webpack-plugin. The repository has 24 CI workflow files and a tests directory, evidence of broad internal checking. Neither fact proves that a private loader or a plugin importing webpack/lib/* will behave the same. Keep webpack installed until those dependencies are replaced or verified.
What happened when we ran it
Our sandbox installed commit 1032815 in 24 seconds. Pnpm added 1,230 packages, and the resulting dependency tree occupied 884 MB on disk. The run used an unprivileged lab-node:22 container with 3 CPUs, 8 GB of RAM, and no secrets. Installation succeeded without a reported error, so obtaining the contributor dependencies worked in that clean environment.
Build and tests did not fail. They were skipped because our generic runner found no build script or target and no test script or target at the repository entry point. That distinction matters: this run provides no passing build or test evidence. The checkout does contain a tests directory, and 24 CI workflows signal that maintainers use more specific automation. A contributor needs the documented package-level workflow instead of guessing that the usual two pnpm commands cover the monorepo.
Thirteen native targets still leave a Wasm fallback
Rspack v2 documents 13 native target combinations across macOS, Linux, and Windows. The list includes glibc and musl Linux builds plus several architectures. For a platform without a native binding, the quick start points to @rspack/binding-wasm32-wasi. That fallback broadens where Rspack can start, though a team should test its own workload rather than assume the Wasm path behaves or performs like a native package.
Runtime requirements can force changes before bundler configuration does. Version 2 needs Node.js 20.19+ or 22.12+, while version 1 supports an older Node line. The migration guide recommends keeping Node consistent across developer machines, CI, and deployment builds. That requirement is easy to miss when the application itself still runs on an older runtime. The 884 MB contributor install also argues for checking CI cache and workspace budgets before moving repository-level work onto small runners.
A same-day v2.2.6 release shows active maintenance
GitHub published Rspack v2.2.6 on September 17, 2026, and the repository was pushed again that day. The release contains loader, source-map, Module Federation, watch, and code-splitting work. GitHub also reported 12,921 stars and 224 open issues and pull requests. The combined count is a queue of work and discussion, not a count of confirmed bugs.
Current activity does not remove adoption risk. Open issue 14089 reports different minified variable names across repeated production builds, which matters to content-addressed caches. Another open report describes a pnpm symlink case where a nested TypeScript configuration cannot be resolved. With 1,230 packages in our checkout and a fast-moving v2 release line, pin the toolchain and compare repeated production output before making it the only build path.
Choose Rspack when webpack compatibility pays for the migration
An 884 MB contributor dependency tree and skipped root checks make Rspack look heavier from inside the repository than it does from an application's package file. That is not a reason to reject it. It is a reason to separate two evaluations: whether @rspack/core can build your app correctly, and whether your team wants to contribute to or debug the Rust and pnpm monorepo. The first can be a contained branch experiment. The second needs more setup.
Rspack earns a serious trial for a webpack 5 estate with custom loaders, Module Federation, or enough applications to make one migration reusable. Run both bundlers in CI, compare emitted files, exercise watch mode, and remove webpack only after the plugin graph is clean. If you are starting with no webpack assumptions, Vite or Rolldown offers a more direct choice. Our 24-second install says Rspack is easy to fetch. Compatibility testing decides whether it is safe to keep.