Repository navigation
Conversation
…atch mode When using runtimeChunk: "single" with splitChunks and contenthash-based filenames, the runtime chunk was being hashed before initial/split chunks. This caused GetChunkFilenameRuntimeModule to embed stale or incorrect content hashes into __webpack_require__.u, leading to broken asset references on watch rebuilds. The fix ensures initial chunks are always hashed before the runtime chunk, consistent with the comment at createHash() that states "all non-runtime chunks need to be hashed first, since runtime chunk might use their hashes." Fixes webpack#20710
🦋 Changeset detectedLatest commit: 4923b29 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Entry chunks may depend on the runtime chunk hash (via createChunkHashHandler for ESM/CJS entries that import the runtime). By splitting them into a 4th dedicated hashing pass after runtime chunks, hash dependencies always flow in one direction: async/initial → runtime → entry Also updates the comment block to document all four hashing categories and their dependency relationships.
Add an assertion that tracks the split chunk filename across watch steps and confirms it updates when the shared module changes. This directly targets the stale-hash symptom: with the buggy hashing order the runtime embeds the step-0 hash and the referenced file does not exist at runtime.
Member
|
Thanks for the PR. This uses the same fix as an earlier PR #20724, so it’s a duplicate and has been closed. If this was submitted automatically by AI, please check for related PRs first. Also, it’d be best to follow the PR template when writing the description. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #20710
When using
runtimeChunk: "single"together withsplitChunksandoutput.filename: "[contenthash].js", watch rebuilds could produce a runtime chunk that references the wrong content-hashed filename for split chunks. This caused the runtime's__webpack_require__.umapping to point to a non-existent file, breaking chunk loading on rebuild.Root cause: In
Compilation.createHash(), runtime chunks were being hashed before initial/split chunks.GetChunkFilenameRuntimeModule(which generates the__webpack_require__.ufilename map) reads each split chunk'scontentHashat hash time. Because the split chunks hadn't been hashed yet, it used a stale value from the previous compilation, producing an incorrect module hash. This caused the asset cache to return the previous compilation's runtime asset on subsequent rebuilds, embedding the old split chunk filename.This contradicts the comment already present in the same method:
Fix: Swap the order so initial chunks are hashed before runtime chunks.
Test plan
test/watchCases/long-term-caching/contenthash-with-runtime-chunk/which reproduces the issue: