Rspack 2.0 Beta.8 Brings Tree Shaking Gains, ESM Node Support, Performance Boosts

The Rspack project, which has accumulated 12.6k GitHub stars as one of the most closely watched Rust-native bundlers in the webpack orbit, shipped v2.0.0-beta.8 on March 24 with a focused package of correctness improvements, new features, and performance work aimed at production-scale JavaScript and TypeScript builds.

The headline addition is tree shaking for inlined member-access dynamic imports, contributed by ahabhgk in pull request #13381. Previously, Rspack's dead-code analysis had limited visibility into dynamic import call sites where code accessed module members inline, meaning some unreachable exports survived into the final bundle. The fix plugs that gap, reducing output size in codebases that rely heavily on dynamic code splitting with member-access patterns.

Alongside it, JSerFeng added an EsmNodeTargetPlugin in PR #13370, a purpose-built plugin for handling Node.js built-in externals when emitting ESM-targeted output. Node's native ESM support has been a rough edge for bundlers historically; the new plugin gives Rspack users a cleaner path to producing ESM libraries and applications that run without shims on modern Node runtimes.

On the performance side, jerrykingxyz landed parallel write support for rspack_storage (#13407), addressing an IO bottleneck that showed up particularly in large monorepo builds and CI environments where compilation artifacts are written frequently. The code splitter also received data structure work from LingyuCoder, who swapped out ukey collections (#13309), and from hardfist, who replaced unnecessary usize and u64 integers with u32 types (#13338), trimming memory overhead inside the inner build graph.

ahabhgk also contributed mangle exports support for CommonJS re-exports (#13413), and JSerFeng fixed ESM library output to stop emitting webpack_require and unnecessary runtime chunks when runtimeChunk is set to false (#13374), a detail that had been quietly inflating ESM library bundles.

Beta.8 arrived just three days before beta.9, published March 27, which signals the pace the web-infra-dev team is maintaining as Rspack 2.0 closes in on a stable release. Each iteration in the series tackles specific production-readiness concerns: tree shaking correctness, ESM output fidelity, and throughput at scale. Those are exactly the concerns that have kept many teams on aging webpack configurations long past the point where faster alternatives existed.

Rspack sits inside a broader Rust-powered toolchain alongside SWC, Rsbuild, and Rspress, all pushing compute-heavy front-end work into native binaries. For teams still running the migration math, beta.8 makes the case one pull request at a time: the gap between webpack parity and native-speed bundling is closing with each tagged release.