fix: force-load a module's new owning chunk when its only loaded chunk leaves a runtime during HMR#21127
fix: force-load a module's new owning chunk when its only loaded chunk leaves a runtime during HMR#21127alexander-akait wants to merge 7 commits into
Conversation
…k migrates runtimes Encodes the scenario described by the TODO in HotModuleReplacementPlugin (force load one of the chunks which contains the module): when a module's only loaded chunk is removed from a runtime but the module survives in that runtime via a not-yet-loaded async chunk, the update removes the chunk without disposing the module, leaving it orphaned.
🦋 Changeset detectedLatest commit: 121d021 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 |
|
This PR is packaged and the instant preview is available (121d021). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@121d021
yarn add -D webpack@https://pkg.pr.new/webpack@121d021
pnpm add -D webpack@https://pkg.pr.new/webpack@121d021 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #21127 +/- ##
==========================================
+ Coverage 92.00% 92.54% +0.53%
==========================================
Files 581 581
Lines 61456 64876 +3420
Branches 16795 18541 +1746
==========================================
+ Hits 56545 60040 +3495
+ Misses 4911 4836 -75
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Merging this PR will degrade performance by 22.74%
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing |
When a module's only loaded chunk is removed from a runtime but the module still lives there via another (not-yet-loaded) chunk, the hot update removed the chunk without disposing the module, leaving it orphaned with no installed chunk owning it — so later HMR updates never reached that runtime. The plugin now emits the new owning chunk id in a manifest `f` field and the JS HMR runtime force-loads those chunks during the update. Implements the long-standing TODO in HotModuleReplacementPlugin.
…check Fold the force-load into the existing ensureChunkHandlers guard and rely on the idempotent ensure handlers (which skip already-installed chunks) instead of re-checking installedChunks.
…runtime check Adds tests for the cross-runtime dispose path and the non-unique hotUpdateMainFilename merge path (which now also carries force-load chunks), and collapses the runtime-membership check to a single expression.
Runs the force-load runtime branch end-to-end on the web target: a module migrates from a shared (multi-runtime) chunk into an async chunk on update, and the runtime force-loads it so the module stays installed. Gated to the web target since the node/webworker harness can't resolve the async chunk file mid-update.
…e collision Covers the branch that merges force-load chunk ids across runtimes when output.hotUpdateMainFilename is not unique per runtime: one runtime migrates a module into an async chunk (producing a force-load chunk) while another changes differently, so their updates collide and are merged (with the expected warning). Web target only, like the sibling force-load test.
| if (forceLoadChunks) { | ||
| forceLoadChunks.forEach(function (chunkId) { | ||
| Object.keys($ensureChunkHandlers$).forEach(function (key) { | ||
| $ensureChunkHandlers$[key](chunkId, promises); |
|
Superseded by #21131 — same commits, branch renamed from Generated by Claude Code |
Summary
Resolves the long-standing TODO in
lib/HotModuleReplacementPlugin.js("force load one of the chunks which contains the module"). In a multi-runtime build, when a module's only loaded chunk is removed from a runtime but the module survives there via a not-yet-loaded async chunk, the update removed the chunk (r) without disposing the module (mstayed empty) — leaving it loaded on the client with no installed chunk owning it, so later HMR updates to it were never delivered. The update manifest now carries a newf(force-load) field listing such chunks, and the runtime ensures them so the client keeps an installed owner. If the module no longer lives in the runtime at all, it is still disposed as before.What kind of change does this PR introduce?
fix
Did you add tests for your changes?
Yes — unit tests in
test/HotModuleReplacementPlugin.test.js(force-load, dispose-when-gone, and cross-runtime merge on filename collision) plushotCasesintegration tests undertest/hotCases/chunks/force-load-migrated-chunkand.../force-load-runtime-collision.Does this PR introduce a breaking change?
No.
If relevant, what needs to be documented once your changes are merged or what have you already documented?
n/a
Use of AI
AI (Claude Code) was used to investigate the TODO, build the reproduction, implement the fix, and author the tests. All output was reviewed and verified by running the suite locally.