feat: allow external modules place in async chunks in some case#20632
feat: allow external modules place in async chunks in some case#20632alexander-akait merged 3 commits intomainfrom
Conversation
|
|
This PR is packaged and the instant preview is available (40023cb). Install it locally:
npm i -D webpack@https://pkg.pr.new/webpack@40023cb
yarn add -D webpack@https://pkg.pr.new/webpack@40023cb
pnpm add -D webpack@https://pkg.pr.new/webpack@40023cb |
Merging this PR will degrade performance by 22.33%
Performance Changes
Comparing 
|
I think for |
The external module behaves more like a proxy module. For the following code: the current behavior results in one single async load, as is the original code. 
If we place the external module into its own chunk, we will generate one new async chunk and it would introduce two async loads. In my view, since the external module essentially acts as a proxy, we can ideally avoid the first loading. 
|
|
@hai-x Got it, agree |
hai-x
force-pushed
the
external-module-chunk-condition
branch
from
be5a620 to
79d2812
Compare
| import external2 from "external2"; | ||
|
|
||
| export const readFile = external.readFile; | ||
| export const readFileSync = external2.readFileSync; |
There was a problem hiding this comment.
Can we use __webpack_modules__ to test it? Using toMatch and not.toMatch often is very hard to maintenance and rewrite when somethings changed?
|
Done. Thanks for the review. |
2 participants
Summary
Fixes #20362.
What kind of change does this PR introduce?
chunkConditiondetermines whether a module can be placed in a chunk, whether initial or async.Note that
import()externals, we still keep them in the initial chunk to avoid loading them asynchronously twice and to improve runtime performance. e.g.ExternalModuleissued byRemoteModule, it should be placed in entry chunks to ensure they are loaded and initialize first due to module federation requirement.Did you add tests for your changes?
Yes
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?
Use of AI
No