我得到的一般要点是,CommonsChunkPlugin
查看所有入口点,检查它们之间是否有公共的包/依赖项,并将它们分离到自己的包中。
因此,让我们假设我有以下配置:
...
enrty : {
entry1 : 'entry1.js', //which has 'jquery' as a dependency
entry2 : 'entry2.js', //which has 'jquery as a dependency
vendors : [
'jquery',
'some_jquery_plugin' //which has 'jquery' as a dependency
]
},
output: {
path: PATHS.build,
filename: '[name].bundle.js'
}
...
如果我不使用CommonsChunkPlugin
进行捆绑
我将以3个新的包文件结束:
entry1.bundle.js
包含来自entry1.js
和jquery
的完整代码,并包含自己的runtimeentry2.bundle.js
,其中包含来自entry2.js
和jquery
的完整代码,并包含自己的runtimevendors.bundle.js
,其中包含来自jquery
和some_jquery_plugin
的完整代码,并包含自己的运行时这显然很糟糕,因为我可能会在页面中加载3次jquery
,所以我们不希望发生这种情况。
如果我使用CommonsChunkPlugin
捆绑
根据我传递给CommonsChunkPlugin
的参数的不同,可能会发生以下情况:
{ name : 'commons' }
,我将得到以下包文件:- `entry1.bundle.js` which contains the complete code from `entry1.js`, a requirement for `jquery` and does not contain the runtime
- `entry2.bundle.js` which contains the complete code from `entry2.js`, a requirement for `jquery` and does not contain the runtime
- `vendors.bundle.js` which contains the complete code from `some_jquery_plugin`, a requirement for `jquery` and does not contain the runtime
- `commons.bundle.js` which contains the complete code from `jquery` and contains the runtime
这样,我们最终得到了一些更小的包,运行时包含在commons
包中。相当不错,但不是很理想。
{ name : 'vendors' }
,我将得到以下包文件:- `entry1.bundle.js` which contains the complete code from `entry1.js`, a requirement for `jquery` and does not contain the runtime
- `entry2.bundle.js` which contains the complete code from `entry2.js`, a requirement for `jquery` and does not contain the runtime
- `vendors.bundle.js` which contains the complete code from `jquery` and `some_jquery_plugin` and contains the runtime.
同样,通过这种方式,我们最终得到了一些更小的包,但运行时现在包含在vendors
包中。这比前一种情况更糟糕,因为运行时现在位于vendors
包中。
{ names : ['vendors', 'manifest'] }
,我将得到以下包文件:- `entry1.bundle.js` which contains the complete code from `entry1.js`, a requirement for `jquery` and does not contain the runtime
- `entry2.bundle.js` which contains the complete code from `entry2.js`, a requirement for `jquery` and does not contain the runtime
- `vendors.bundle.js` which contains the complete code from `jquery` and `some_jquery_plugin` and does not contain the runtime
- `manifest.bundle.js` which contains requirements for every other bundle and contains the runtime
这样,我们最终得到了一些更小的包,运行时包含在manifest
包中。这是最理想的情况。
我不明白的/我不确定我明白了
jquery
)和vendors
条目(some_jquery_plugin
)的vendors
包?据我所知,CommonsChunkPlugin
在这里所做的是收集公共代码(jquery
),因为我们强制它将其输出到vendors
包,所以它将公共代码“合并”到vendors
包中(它现在只包含来自some_jquery_plugin
的代码)。请确认或解释。 { names : ['vendors', 'manifest'] }
传递给插件时发生了什么。为什么/如何保持vendors
包完好无损,同时包含jquery
和some_jquery_plugin
,而jquery
显然是一个常见的依赖项,为什么生成的manifest.bundle.js
文件按照创建的方式创建(需要所有其他包并包含运行时) ?发布于 2016-09-21 01:58:44
这就是CommonsChunkPlugin
的工作方式。
一个公共块“接收”由几个条目块共享的模块。复杂配置的一个很好的例子可以在Webpack repository中找到。
CommonsChunkPlugin
在Webpack的优化阶段运行,这意味着它在内存中操作,就在区块被密封并写入磁盘之前。
当定义了几个公共块时,将按顺序处理它们。在你的例子3中,它就像是运行了两次插件。但请注意,CommonsChunkPlugin
可能具有更复杂的配置(minSize、minChunks等),这会影响模块的移动方式。
案例1:
entry
区块(entry1
、entry2
和vendors
).commons
区块设置为公共区块。commons
公共区块(由于该区块不存在,因此会创建它):<代码>G118<代码>H119它收集在其他区块中多次使用的模块:<代码>D20,entry2
和vendors
使用jquery
,因此模块将从这些区块中删除并添加到commons
区块中。commons
区块被标记为entry
区块,而entry1
、D30和D31区块则未被标记为so
commons
块是一个entry
块,因此它包含运行时和jquery
模块。案例2:
entry
区块(entry1
,entry2
和vendors
).vendors
区块设置为公共区块。vendors
公共区块:entry1
和entry2
使用D62,因此将从这些区块中删除模块(请注意,不会将其添加到D63区块中,因为D64区块已经包含它)。H265H166区块被标记为D68区块而未标记为entry
.的entry1
和entry2
区块
vendors
块是一个entry
块,因此它包含运行时和jquery
/jquery_plugin
模块。案例3:
entry
区块(entry1
,entry2
和vendors
).vendors
区块和manifest
区块设置为公共区块。manifest
区块,因为它不存在。vendors
公共区块:<代码>G1102<代码>H1103它收集在其他区块中多次使用的模块:D104和D105使用D106,因此该模块将从这些区块中删除(请注意,不会将其添加到D107区块中,因为vendors
区块被标记为entry
区块,而entry1
和entry2
区块未被标记为entry
区块
manifest
公共区块(由于该区块不存在,因此会创建它):manifest
区块标记为entry
区块,而D129、D130和D131未标记为entry
.
manifest
块是一个entry
块,因此它包含运行时。希望能有所帮助。
https://stackoverflow.com/questions/39548175
复制相似问题