Planned breaking changes for Rspack 3.0

[chenjiahan]

Rspack 2.0 was released on April, 2026. We plan to release Rspack 3.0 18–24 months later, between October 2027 and April 2028.

This discussion tracks potential breaking changes for Rspack 3.0 in advance. Proposals are open for feedback and may change before the final release.

Reference: Planned breaking changes for Rspack 2.0

[chenjiahan]

Move NW.js support to a separate package

Moving NW.js support from Rspack core to a dedicated package in Rspack 3.0.

This would reduce platform-specific complexity in the core while allowing NW.js integration to be maintained independently.

[intellild]

require x86_64-v2 or x86_64-v3 , drop windows i686 support

[chenjiahan]

Could you share a bit more context?

[intellild]

i686 is 32-bit platform released in 1995 https://en.wikipedia.org/wiki/P6_(microarchitecture)
(I don't think anyone can find a working real i686 machine, except a 64-bit modern CPU running under compatibility mode)

https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
x86-64-v2 requires cpus released after 2008.
x86-64-v3 requires cpus released after 2013 for intel and 2015 for AMD.
Modern operating systems require v2, such as RHEL 9 , while RHEL 10 requires v3.

Actually there was a bug in rspack #14701 that old CPUs won't work.

[intellild]

The CPU in the bug meets the requirements of x86-64-v3
The bug is discovered by a wrong hypervisor configuration, and the debug and test is done by QEMU simulating a really old CPU.

[hardfist]

Remove experiments.futureDefaults support

Remove support for experiments.futureDefaults in Rspack 3.0.

The option still defaults to false, but enabling it no longer changes other built-in defaults in Rspack. The existing defaults snapshot only changes the flag itself.

Keeping this option suggests that it previews next-major defaults, which is misleading. Remove it to simplify configuration, and use explicit feature options when needed.

Migration: delete experiments.futureDefaults from your configuration.

[intellild]

remove RuleSetLoaderWithOptions.parallel.maxWorkers

• Misleading scope: maxWorkers is configured per loader but controls a shared worker pool.
• Order-dependent behavior: The first loader to initialize the pool determines its size.
• Silently ignored settings: Subsequent loaders’ maxWorkers values have no effect.

[intellild]

environment variable RSPACK_LOADER_WORKER_THREADS should be used instead

[chenjiahan]

I think this deserves more discussion, as an environment variable may not be the best configuration API. We could explore some alternatives:

• Automatically use separate worker pools for different loader settings.
• Let users explicitly configure worker pools and choose which loaders share them.