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

[mjames-c]

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:

rspack/packages/rspack/src/loader-runner/index.ts

Lines 1214 to 1216 in 94795bd

	if (compiler.options?.cache) {
	commitCustomFieldsToRust(context._module.buildInfo);
	}

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:

rspack/crates/rspack_binding_api/src/module.rs

Line 141 in 94795bd

fn module_build_info_getter(ctx: CallContext) -> napi::Result<Object> {

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.

[SyMind]

@mjames-c Thanks for the detailed report and repro — your analysis of the mechanics is accurate.

To clarify the intended semantics: buildInfo.extras exists to bridge JS-side custom buildInfo fields into the persistent cache. It is not a real-time Rust → JS channel, and architecturally cannot be one — Rust writes happen on worker threads where calling back into JS is impossible, so a JS-side snapshot of extras is stale by construction. (Cache disabled "working" is incidental timing, not guaranteed behavior.)

For data that flows between Rust and JS with always-fresh reads, @rspack/core exposes explicit typed getters/setters on KnownBuildInfo, which read/write Rust state directly and never go stale.

So: does your use case really require passing data from Rust to JS via module.buildInfo? If yes, please share what data it is and who consumes it — if it's a common need we'd rather expose an explicit field. If the data only travels between loaders, channels like additionalData may be a better fit.