fix: sometimes entry chunk hash not changes with full hash runtime modules#9986
fix: sometimes entry chunk hash not changes with full hash runtime modules#9986
Conversation
✅ Deploy Preview for rspack canceled.
|
CodSpeed Performance ReportMerging #9986 will not alter performanceComparing 🎉 Hooray!
|
c8cf593 to
bdecf94
Compare
There was a problem hiding this comment.
Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.
Comments suppressed due to low confidence (1)
crates/rspack_plugin_runtime/src/helpers.rs:150
- [nitpick] Consider revising the error message from 'should has entry point ukey' to 'should have an entry point ukey' for improved grammatical clarity.
.next().ok_or_else(|| error!("should has entry point ukey"))?;
| dist: path.resolve(__dirname, `./js/new-incremental/watch`) | ||
| dist: path.resolve(__dirname, `./js/new-incremental/watch`), | ||
| // TODO: fix this test case | ||
| exclude: [/runtimeChunkFullHash/] |
There was a problem hiding this comment.
This case can not work with new incremental, perhaps we need to handle this in https://github.com/web-infra-dev/rspack/blob/main/crates/rspack_core/src/incremental/mutations.rs#L146-L148 @ahabhgk
Summary
fix #9985
In this repro https://github.com/hikerpig/module-runtimechunk-repro, the combination of
chunkFormat: moduleandruntimeChunk: truecauses the entry chunk to import the runtime chunk viaimport __webpack_require__ from "./runtime~main.857eaa3b.js";.This leads to a situation, when relying on full hash (such as the entry injected by the dev server), during incremental builds in the dev mode, changes of the full hash will cause changes in the content of the runtime chunk. If the filename of the runtime chunk contains
[contenthash], then its final filename will change. At this time, due to the above mentionedimportstatement, the content of the entry chunk will also change, and consequently, its[contenthash]will change.However, when rspack calculates the
contenthashof a chunk, it doesn't take this scenario into account. Because the entry chunk itself has no real relation to these changes, and the import statement is startup code injected during the code generation of the chunk. So when these contents change, the contenthash and chunkhash of the entry chunk in rspack won't change. As a result, the chunk code generation cache takes effect, and the runtime chunk from the previous compilation is referenced.In Webpack, when adding a runtime module, the runtime module is associated with this chunk. When handling the chunk hash, for normal chunks, it also checks whether they contain full hash modules just like runtime chunks, and then includes the chunk in the hash update process of full hash chunks. However, in rspack, this associative relationship doesn't exist, and the chunk hash only deals with the full hash update of runtime chunks.
So this PR only applies to the scenarios of
commonjsandmodulechunkFormats. If they introduce the loading statement of the runtime chunk, then this entry chunk will be added to the full - hash update, causing the cache of this entry chunk to become invalid, thus fixing this issue.However, in the
new incremental,Mutation::ModuleSetHashesonly affects the chunks associated with the module. This causes the chunk hashing process to be skipped, and the problem still persists. I haven't found a good solution to this.Checklist