Background

In Rsbuild / Rspack / Webpack, updating a Vue SFC may trigger a JavaScript module hot update even when only non-JS parts (such as <template> or <style>) have changed. This behavior causes component state to be reset and deviates from the expected Vue HMR semantics.

Related issue: web-infra-dev/rsbuild#3217 (comment)

Root Cause

The issue is caused by changes in the generated sourcemap rather than changes in the emitted JavaScript code.

During rebuilds, a new sourcemap is generated on every update, even when the JavaScript output remains identical. Since the HMR mechanism determines module updates based on emitted assets (including sourcemaps), any change in the sourcemap is sufficient to mark the JS module as updated, resulting in an unnecessary hot update.

Current Approach

keeping the sourcemap stable when the JS output is unchanged.

When the loader detects that the generated JavaScript code has not changed, it reuses the previously generated sourcemap instead of producing a new one. By keeping the sourcemap unchanged, the JS module is no longer considered updated, preventing unnecessary JS HMR and preserving component state.

As a result, component state can be preserved during template or style-only updates.

This approach is similar to how unplugin-vue handles updates via the Vite's handleHotUpdate hook. Since the need to adjust hot update behavior mainly comes from Vue HMR scenarios, we believe it is more appropriate to handle this logic internally within vue-loader or unplugin-vue, rather than at a higher level.

Known Limitations

Reusing the previous sourcemap may lead to slightly inaccurate source mappings for <template> and <style> sections. However, in practice, this has minimal impact on debugging and is considered an acceptable trade-off compared to the benefit of avoiding unnecessary JavaScript hot updates.