#15442·rspack

[Bug]: `module.buildInfo` becomes stale when caching is enabled and `buildInfo` is mutated by a native loader

Author: mjames-cCreated Sep 3, 2026Updated Sep 16, 2026
Labelspending triage

System Info

  • @rspack/core: 2.2.2
  • node.js: 24.12.0

Details

When caching is enabled, JS side module.buildInfo can become stale if:

  1. A JavaScript loader runs.
  2. Rspack yields to a subsequent native loader and said loader adds custom fields to the module's Rust BuildInfo.extras.
  3. A JavaScript plugin later reads module.buildInfo.

The native fields are missing from the JavaScript object. Disabling caching makes them visible.

Suspected cause

At the end of each JavaScript loader-runner invocation, caching causes Rspack to read context._module.buildInfo:

https://github.com/web-infra-dev/rspack/blob/94795bda0a6c481bacdda5f40ceb8313bb08e6c5/packages/rspack/src/loader-runner/index.ts#L1214-L1216

When the next loader is native, the JavaScript runner yields before that loader executes. The expression above therefore reads module.buildInfo before the native loader adds its extras.

The binding getter creates and caches a JavaScript build-info object:

https://github.com/web-infra-dev/rspack/blob/94795bda0a6c481bacdda5f40ceb8313bb08e6c5/crates/rspack_binding_api/src/module.rs#L141

Subsequent accesses return the cached object without refreshing it from the Rust module. The native loader updates BuildInfo.extras, but the previously created JavaScript object remains stale.

Reproduce link

https://github.com/mjames-c/rspack-caching-bug

Reproduce Steps

See README in repro link.