Repository navigation
refactor(module): add internal parser/generator lifecycle for incremental rebuilds - #21555
Conversation
|
328a541 to
a6df7b2
Compare
|
This PR is packaged and the instant preview is available (afd3006). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@afd3006
yarn add -D webpack@https://pkg.pr.new/webpack@afd3006
pnpm add -D webpack@https://pkg.pr.new/webpack@afd3006 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## refactor/exports-info-reset-apis #21555 +/- ##
====================================================================
- Coverage 93.80% 93.80% -0.01%
====================================================================
Files 622 622
Lines 74500 74508 +8
Branches 21616 21617 +1
====================================================================
+ Hits 69885 69889 +4
- Misses 4615 4619 +4
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 13.24%
|
| Mode | Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|---|
| ❌ | Memory | benchmark "asset-modules-resource", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
660.4 KB | 1,242.7 KB | -46.86% |
| ⚡ | Memory | benchmark "asset-modules-inline", scenario '{"name":"mode-development-rebuild","mode":"development","watch":true}' |
395.3 KB | 279.1 KB | +41.65% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing refactor/module-parser-lifecycle (895ffe0) with refactor/exports-info-reset-apis (888d134)
…l rebuilds Reset provide-side and use-side export info to the undetermined state so FlagDependencyExports/FlagDependencyUsage can recompute them against a persisted module graph. No behavior change.
…exports Mirror setHasUseInfo: _resetUseInfo recurses into an owned nested exportsInfo and _resetUsedExports follows the redirect target, so no stale usage survives a use-only reset.
…ale inlined flag Reset an owned nested exportsInfo in place instead of discarding it (its use state must survive a provide-only reset), and clear the _hasInlinedExports fast-path flag when use info is reset.
a6df7b2 to
e93bb4d
Compare
…s info After a provide reset the nested exports are back to undefined, and FlagDependencyExports only upgrades provided from false/null, so the module-level re-init must reach nested exports (mirrors setHasUseInfo).
The redirect points into another module's exports info; the global incremental reset loop already resets it via its own module, so following it wiped foreign state (and double-reset shared targets).
Assert use-state resets through the public getUsed/getUsedName API instead of private fields, and cast the setTarget/canInlineProvide fixtures.
…ntal rebuilds _cleanupParserForCache releases the parser between rebuilds so it does not retain the previous compilation; _restoreParserAndGenerator re-acquires both from the factory so the new compilation's plugin hooks apply. AsyncQueue.invalidate now tolerates items absent from the current run. No behavior change.
e93bb4d to
c121b43
Compare
Summary
Adds an internal parser/generator lifecycle to
Module/NormalModule(_cleanupParserForCachereleases the parser so it does not retain the previous compilation;_restoreParserAndGeneratorre-acquires both from the factory so the new compilation's plugin hooks apply), and makesAsyncQueue.invalidatetolerate items absent from the current run. No behavior change; third PR of the incremental-rebuilds series (stacked on #21553, extracted fromperf/incremental-rebuild).What kind of change does this PR introduce?
refactor
Did you add tests for your changes?
Yes, new cases in
test/NormalModule.unittest.jsandtest/AsyncQueue.unittest.js.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 extract this change from my working branch, adapt it onto current
main, and draft the unit tests; I reviewed and validated everything locally.Note
Low Risk
Internal hooks and a defensive guard in AsyncQueue with no current call sites in this diff; behavior change is limited to invalidate on absent keys, which is explicitly tested.
Overview
Prepares incremental rebuilds by introducing internal lifecycle hooks on
Module/NormalModulefor factory-derived parser and generator instances._cleanupParserForCachedrops the cached parser so it does not retain the previous compilation._restoreParserAndGeneratorre-fetches parser and generator fromNormalModuleFactoryso the new compilation’s plugin hooks apply. BaseModuledefines no-op stubs;NormalModuleimplements them (parser-only cleanup vs full restore). This PR does not wire these hooks into compilation yet—they are scaffolding for the incremental-rebuild stack.AsyncQueue.invalidatenow returns immediately when there is no entry for the key (e.g. invalidating modules from a persisted graph that were not added in the current run), instead of assuming an entry exists.Unit tests cover the
NormalModulelifecycle and the no-op invalidate path.Reviewed by Cursor Bugbot for commit 895ffe0. Bugbot is set up for automated code reviews on this repo. Configure here.