feat: report changed compilers on MultiCompiler done hook - #21580
Conversation
🦋 Changeset detectedLatest commit: b5ce145 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 |
9afa9c1 to
57211e8
Compare
|
This PR is packaged and the instant preview is available (40e41b9). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@40e41b9
yarn add -D webpack@https://pkg.pr.new/webpack@40e41b9
pnpm add -D webpack@https://pkg.pr.new/webpack@40e41b9 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #21580 +/- ##
=======================================
Coverage 94.01% 94.02%
=======================================
Files 624 624
Lines 75802 75806 +4
Branches 22086 22086
=======================================
+ Hits 71269 71273 +4
Misses 4533 4533
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 improve performance by 44.59%
Performance Changes
Tip Curious why this is faster? Comment Comparing 
|
alexander-akait
left a comment
There was a problem hiding this comment.
I am afraid it is a breaking change, we should pass it in the third argument, what do you think?
|
Nevermind I was wrong, bad diff on mobile |
Summary
The aggregated
donehook ofMultiCompileralways emits the fullMultiStats, so consumers cannot tell which child compilers actually rebuilt in a cycle — webpack-dev-middleware for example is forced to keep a single all-or-nothing valid/invalid state and block requests for every bundle while any child rebuilds. This passes the compilers that rebuilt since the previous aggregateddoneas an additive second hook argument, exposing bookkeepingMultiCompileralready tracks internally.What kind of change does this PR introduce?
feat
Did you add tests for your changes?
Yes, in
test/MultiCompiler.test.js(initial build reports all compilers, invalidating a single child reports only that one).Does this PR introduce a breaking change?
No, the argument is additive; existing
donetaps are unaffected.If relevant, what needs to be documented once your changes are merged or what have you already documented?
Document the
changedCompilersargument ofmultiCompiler.hooks.donein the Node API docs.Use of AI
This PR was implemented with AI assistance (Claude Code), directed and reviewed by me.
Note
Low Risk
Additive hook argument only; existing
donelisteners that ignore the second parameter should behave as before, with a small change to internal aggregation bookkeeping.Overview
multiCompiler.hooks.donenow receives a second argument,changedCompilers: the childCompilerinstances that finished a build since the previous aggregateddone(still paired with the fullMultiStats).Tracking reuses the existing per-child
done/invalidcoordination: each childdoneadds that compiler to a set, and when all children have reported in, the hook fires with compilers in multi-compiler order before the set is cleared.This is an additive Node API change (minor release per changeset); typings in
types.d.tsare updated, and a watch test asserts an initial cycle lists all compilers while invalidating one child lists only that one.Reviewed by Cursor Bugbot for commit b5ce145. Bugbot is set up for automated code reviews on this repo. Configure here.