Overly restrictive condition in module concatenation #14431
dmichon-msft
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Tags: Module concatenation, Optimization ,Bailout, Tree
The bailout condition for only including a module in concatenation if all references to it are in the same chunks as the concatenated module is overly restrictive and leaves a lot of optimization potential on the table:
webpack/lib/optimize/ModuleConcatenationPlugin.js
Lines 635 to 645 in 7666277
A particularly common case where this criteria gives suboptimal results is for any module that is synchronously loaded in the initial chunk, then referenced in async chunks. Although it is referenced from other chunks, those chunk load strictly after the concatenated module, and thus scope hoisting would still be beneficial. It would, however, require remapping the imports in the later chunks.
A slightly more relaxed but still technically correct condition is that the root module of the concatenated module must already be present in the synchronous dependency graph of each origin module. The most correct would be that the flattened synchronous dependencies of every entry point or async imported module of the graph include both the root and candidate module, or neither of them. This equates to that the concatenation will never increase the set of modules that will be evaluated in webpack's current round of module evaluation.
Beta Was this translation helpful? Give feedback.
All reactions