fix: reset lazy barrel deferral in every compilation - #22401

⚠️ No Changeset found

Latest commit: c877316

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

No actionable comments were generated in the recent review. 🎉

Priority: ➖ Normal

Change: Bug fix

Merge Risk: ⚪ Minimal · up to c8773

The reviewed change addresses stale lazy state across compilations, with no actionable merge-blocking risk identified. The watch tests were not run as part of this assessment.

Security Architecture Review

Security architecture risk: 🔵 Low · up to eab47

The change fixes which modules are built during rebuilds without showing a new privilege or execution boundary. Remaining uncertainty around interrupted builds and reuse of older build caches keeps the assessment at low risk.

Retained concerns
No architecture-level concerns identified.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

This PR is packaged and the instant preview is available (c877316).

Install it locally:

• npm

npm i -D webpack@https://pkg.pr.new/webpack@c877316

• yarn

yarn add -D webpack@https://pkg.pr.new/webpack@c877316

• pnpm

pnpm add -D webpack@https://pkg.pr.new/webpack@c877316

Types Coverage

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.08%. Comparing base (cb47bb9) to head (c877316).
⚠️ Report is 63 commits behind head on main.

@@             Coverage Diff             @@
##             main   #22401       +/-   ##
===========================================
+ Coverage   77.45%   96.08%   +18.62%     
===========================================
  Files         616      772      +156     
  Lines      116817   122517     +5700     
  Branches    38038    39374     +1336     
===========================================
+ Hits        90482   117716    +27234     
+ Misses      26335     4801    -21534     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

Generated code size

Comparing base (9fd4df5) to head (c877316). Merging this pull request will not change the code webpack generates.

Read Changed, test untouched first: the test is byte-identical on both sides, so webpack generated the difference. Changed, test edited moved partly because the test did — Test edit is how many bytes the test gained, and a bundle that grew by less is not a regression. New and Deleted are whole files, not deltas — a new asset was created, not grown, so it reads gray (⚪ added) — and adding tests cannot bury a real change. Gzip decides, because that is what users download; raw is the tiebreak, and brotli and zstd are per asset below.

No asset changed size.

No runtime gained or lost a runtime module.

Built test/configCases with the defaults a user gets: 2299 test(s), 8312 asset(s), 96 emitted nothing.

Merging this PR will degrade performance by 17.98%

⚡ 2 improved benchmarks
❌ 9 regressed benchmarks
✅ 391 untouched benchmarks
⏩ 6 skipped benchmarks¹

Performance Changes

_{Comparing fix/lazy-barrel-stale-lazy-flags (c877316) with main (cb47bb9)²}

@alexander-akait Could you have one look? I want to merge it first, and there's also a fix for lazy barrel in progress, which will take some time.

CodSpeed memory report: these are runner noise, not this PR. CodSpeed flags every regressed benchmark as compared across different CPUs, and seven of the nine (many-chunks-*, *unsafe-cache, many-modules-esm, css-parser readToken) regress by the same 20–28% between cb47bb9 and 9fd4df5 on main, which only touches the minifier. Against 9fd4df5 they vanish. The remaining two I measured locally with a real webpack() build of the fixtures, base vs head:

Rebasing onto current main should give a clean comparison.

A suggestion for the root cause. The fix resets _lazyMake every compilation, which works, but the flag still lives on the dependency object, which outlives the compilation (watch, memory cache, filesystem cache). Every future reader has to remember that it is only meaningful after LazyBarrels.classify ran in this compilation. The same bug can come back through any new code path that reads it before that, or through a dependency the cache restores.

Since LazyBarrels is already per-Compilation state, the flag could live there instead:

• LazyBarrels keeps a Set<Dependency> of deferred dependencies (or LazyBarrelInfo already knows them via _requestToDepGroup), and exposes isLazy(dependency).
• _createInfo adds to the set instead of dep.setLazy(true); _take deletes instead of dep.setLazy(false).
• The three readers all have the compilation at hand: Compilation.processDependency (this._lazyBarrels), getDeferredExports in ESMImportDependency (called from getWarnings/getErrors, which get moduleGraph), and HarmonyImportDependency.Template.apply (templateContext). Each would ask compilation._lazyBarrels.isLazy(dep) instead of dep.isLazy().
• Dependency#isLazy/setLazy and _lazyMake then go away entirely, along with the serialization concern, because nothing on a cached dependency can carry a stale decision. One caveat: _lazyBarrels.clear() currently runs after finishModules, but the template reads the flag at render time, so the set has to outlive clear() (release it with the compilation instead, or keep only the set past clear()).

That makes "deferred" a fact about this compilation by construction, so neither a rebuild nor the filesystem cache can leak it, and the stale-lazy-import* watch cases would cover it the same way. Happy to leave it to the follow-up lazy barrel PR you mentioned if that's where it fits better.

Generated by Claude Code

@hai-x asked Claude to think how to fix design, feel free to use it