介绍
chunk(module 的集合)在 webpack 解析的依赖图中以父子关系联系起来的。最初CommonsChunkPlugin被设计用于 chunk 之间避免重复依赖，但是性能远远不是最优解。
在 webpack 4 中，内置了ChunkSplitPlugin用于替代CommonsChunkPlugin。
以下基于官方 demo进行梳理，将主要的数据结构结合图示和个人的理解进行总结。
揭开此插件的设计思路和源码神秘面纱
思路
准备
在梳理之前建议先了解一下 webpack 内部基于 tap 事件流架构。
以及 Chunk(
观察 demo 中文件结构，可以简单得出以下结论
- 共有 7 个入口文件 a ～ f.js，也就是最少七个 chunk(分别通过索引 1 ～ 7 来表示)
- 共有 14 个 js 文件，则共有 14 个 module
- stuff/*下的 s1.js~s8.js 和 node_modules/m1~m7.js 之间是没有相互依赖的
插件被注入在 compiler 的thisCompilation的 tap 事件以及 compilation 的optimizeModules的 tap 事件下
thisCompilation:Executed while initializing the compilation, right before emitting the compilation event.
optimizeModules:Called at the beginning of the module optimization phase. A plugin can tap into this hook to perform optimizations on modules.
为了方便后续调试和梳理，特意将 demo 的 14 个文件之间的依赖关系整理出来
[图片上传失败...(image-17842f-1609774367116)]
分别将 7 个入口文件 entryPoint 按颜色区分开来，箭头指向为依赖关系，橘黄色的区域为经过
ChunkSplitPlugin生成的newChunk
以及将执行前的所有 Chunk 快照
[图片上传失败...(image-afe7ac-1609774367116)]
./webpack.config.js
module.exports = {
// mode: "development || "production",
entry: {
pageA: "./pages/a",
pageB: "./pages/b",
pageC: "./pages/c",
pageD: "./pages/d",
pageE: "./pages/e",
pageF: "./pages/f",
pageG: "./pages/g",
},
optimization: {
splitChunks: {
chunks: "all",
maxInitialRequests: 20, // for HTTP2
maxAsyncRequests: 20, // for HTTP2
minSize: 40, // for example only: chosen to match 2 modules
// omit minSize in real use case to use the default of 30kb
},
},
};
前置逻辑
在插件分析整个依赖图整理 module 之间的重复依赖之前，进行了大量的额外的优化，通过空间换时间，将大部分数据状态缓存起来，
以下就通过代码顺序和逻辑一步步进行剖析。
chunkSetsInGraph
通过遍历 14 个 module，分析 module.chunksIterable 被依赖的 Chunk，通过 Chunk 的索引整合成 key 值指向 Chunk 的集合，类型为Map<string, Set<Chunk>>
[图片上传失败...(image-b3db48-1609774367116)]
例如：遍历到 m1 时，该模块被 Chunk1 和 Chunk2 以及 Chunk3 引用，则如图所示 "1,2,4"->set<Chunk>{Chunk1，Chunk2，Chunk3}。
当遍历到 m2 时，发现改模块也被 Chunk1 和 Chunk2 以及 Chunk3 引用，"1,2,3"已经被缓存，则跳过继续遍历
chunkSetsByCount
对chunkSetsInGraph进行遍历，将chunkSet通过 length 聚合。类型为Map<number, Array<Set<Chunk>>>
[图片上传失败...(image-2085c0-1609774367116)]
中推入 key 值为 2 指向[{Chunk1,Chunk3}]数组。
当遍历
combinationsCache
对所有的 ChunkSet 进行遍历，将 ChunkSet 及它的子 Set 进行聚合，通过聚合中的 ChunkSet 最大 key 进行引用。类型为Map<string, Set<Chunk>[]>
[图片上传失败...(image-baf9b6-1609774367116)]
例如：遍历 chunkSetInGraph，当 key 值为1,2,3时,指向[{chunk1,chunk2,chunk3}]，同时后续遍历中将所有 subSet 推入，最后"1,2,3"指向[{chunk1,chunk2,chunk3},{Chunk1,Chunk3},{Chunk1},{Chunk2},{Chunk3}]
selectedChunksCacheByChunksSet
所有的 chunkSet 对应的不同的配置过滤后的结果，基于 webpack.config.js。类型WeakMap<Set<Chunk>, WeakMap<ChunkFilterFunction, SelectedChunksResult>>
在我们的 demo 中chunks: "all"的配置，所有的filterFunction都是const ALL_CHUNK_FILTER = chunk => true;,所以SelectChunkResult都是 chunkSet 本身
[图片上传失败...(image-81589e-1609774367116)]
核心
基于以上的生成的缓存数据，接下来就是开始生成最重要的数据结构chunksInfoMap，同时遍历这个对象剥离出新的 Chunk 并且在 ChunkGroup 中建立联系。类型Map<string, ChunksInfoItem>,ChunksInfoItem 类型为{modules,cacheGroup,name,chunks,chunksKeys,blabla...}
对 modules,combinationCache,以及 cacheGroups 进行三层嵌套循环找出每个被依赖的 module 的重复 chunk 关系（可以尝试对照第一张图逆向推导）
cacheGroups 是中间数据， 遍历每个 module 时生成的配置项，主要用于区分 module 的类型用于过滤
例如：在chunk:all的配置下，module 默认存在配置{key:normal,minChunk: 2},但是node_modules/*下的 m1 ～ m7 除了默认配置额外{key:vendor,minChunk: 1}
例如：遍历到 m1 时，存在两个 cacheGroup 配置项[{key:normal},{key:vendors}]，且在 combinationCache 被{chunk1,chunk2,chunk3} 及子集[{chunk1,chunk3},{chunk1},{chunk2},{chunk3}]依赖。所以基于 key 值分别推入 7 条数据（另外 3 条由于 vendor 的 minChuck 为 2 被过滤）
[图片上传失败...(image-e02411-1609774367116)]
最后对chunksInfoMap循环检索
在每次循环检索，推出优先级最高的ChunksInfoItem(通过 name/path/chunks.lengthd 长度等等)。
通过校验后，使用compilation.addChunk生成一个 newChunk，并且GraphHelpers.connectChunkAndModule将 newChunk 注入 Graph 中，并且通过chunk.removeModule移走旧 chunk 中 newChunk 中的 module。
直至 chunksInfoMap 为空
注意：进入下一次循环前，会将剩余的 ChunksInfoItem 的 module 进行清理，已被封装进入 newChunk 的 module 移除，如果 ChunksInfoItem 的 module 为 0，则这个 chunkInfoItem 被 delete
总结
webpack 极大的解放了前端工程化的劳动力，一个插件中的逻辑都能给予我们大量的启发，并且对于阅读知名的开源项目，源码结构也确实十分严谨和美观，收获颇丰。
由于 demo 比较基础，插件中很多边界情况并没有涉及到，但是主流程梳理的比较完善。
研习大佬的代码，就像阅读一本著作，虽然很痛苦但是却很享受~
作者：洪春
链接：https://juejin.cn/post/6844903823840919565
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
