谁能解释一下 Webpack 的 CommonsChunkPlugin

Question

我知道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 的完整代码，并包含自己的运行时
• entry2.bundle.js 包含来自 entry2.js 和 jquery 的完整代码，并包含自己的运行时
• vendors.bundle.js 包含来自 jquery 和 some_jquery_plugin 的完整代码，并包含自己的运行时

这显然很糟糕，因为我可能会在页面中加载 jquery 3 次，所以我们不希望这样。

如果我使用 CommonsChunkPlugin 捆绑

根据我传递给CommonsChunkPlugin 的参数，将发生以下任何情况：

• 案例1：如果我通过{ name : 'commons' }，我将得到以下捆绑文件：

  • entry1.bundle.js 包含来自 entry1.js 的完整代码，是 jquery 的要求，不包含运行时
  • entry2.bundle.js 包含来自entry2.js 的完整代码，是jquery 的要求，但不包含运行时
  • vendors.bundle.js 包含来自 some_jquery_plugin 的完整代码，是 jquery 的要求，不包含运行时
  • commons.bundle.js 包含来自 jquery 的完整代码并包含运行时

  这样我们最终会得到一些较小的包，并且运行时包含在commons 包中。还可以，但不理想。

• 案例2：如果我通过{ name : 'vendors' }，我将得到以下捆绑文件：

  • entry1.bundle.js 包含来自 entry1.js 的完整代码，是 jquery 的要求，不包含运行时
  • entry2.bundle.js 包含来自 entry2.js 的完整代码，是 jquery 的要求，不包含运行时
  • vendors.bundle.js 包含来自 jquery 和 some_jquery_plugin 的完整代码并包含运行时。

  这样，我们最终会得到一些较小的包，但运行时现在包含在vendors 包中。这比前一种情况要差一些，因为运行时现在位于 vendors 包中。

• 案例3：如果我通过{ names : ['vendors', 'manifest'] }，我将得到以下捆绑文件：

  • entry1.bundle.js 包含来自 entry1.js 的完整代码，是 jquery 的要求，不包含运行时
  • entry2.bundle.js 包含来自entry2.js 的完整代码，是jquery 的要求，不包含运行时
  • vendors.bundle.js 包含来自 jquery 和 some_jquery_plugin 的完整代码，但不包含运行时
  • manifest.bundle.js 包含所有其他捆绑包的要求并包含运行时

  这样我们最终会得到一些较小的包，并且运行时包含在manifest 包中。这是理想的情况。

我不明白/我不确定我是否明白

• 在 CASE 2 中，为什么我们最终会得到包含公共代码 (jquery) 和 vendors 条目 (some_jquery_plugin) 中剩余的任何内容的 vendors 包)?据我了解，CommonsChunkPlugin 在这里所做的是它收集了公共代码 (jquery)，并且由于我们强制它输出到 vendors 包，它有点将公共代码“合并”到vendors 捆绑包（现在只包含来自some_jquery_plugin 的代码）。 请确认或解释。

• 在 CASE 3 中，当我们将 { names : ['vendors', 'manifest'] } 传递给插件时，我不明白发生了什么。为什么/如何保持vendors 捆绑包保持原样，同时包含jquery 和some_jquery_plugin，而jquery 显然是一个常见的依赖项，以及为什么生成的manifest.bundle.js 文件按照它的创建方式创建（需要所有其他包并包含运行时）？

Answer 1

这就是CommonsChunkPlugin 的工作原理。

一个公共块“接收”由几个入口块共享的模块。 在Webpack repository 中可以找到复杂配置的一个很好的示例。

CommonsChunkPlugin 在 Webpack 的优化阶段运行，这意味着它在内存中运行，就在块被密封并写入磁盘之前。

当定义了几个公共块时，它们会按顺序处理。在您的情况 3 中，就像运行插件两次一样。但请注意，CommonsChunkPlugin 可能具有更复杂的配置（minSize、minChunks 等），这会影响模块的移动方式。

案例 1：

1. 有 3 个 entry 块（entry1、entry2 和 vendors）。
2. 配置将commons块设置为普通块。
3. 插件处理commons公共块（由于块不存在，所以创建）：
   1. 它收集在其他块中多次使用的模块：entry1、entry2 和 vendors 使用 jquery，因此模块从这些块中删除并添加到 commons 块中.
   2. commons 块被标记为 entry 块，而 entry1、entry2 和 vendors 块未被标记为 entry。
4. 最后，由于commons 块是entry 块，它包含运行时和jquery 模块。

案例 2：

1. 有 3 个 entry 块（entry1、entry2 和 vendors）。
2. 配置将vendors块设置为普通块。
3. 插件处理vendors公共块：
   1. 它收集在其他块中多次使用的模块：entry1 和entry2 使用jquery，因此模块从这些块中删除（注意它没有添加到vendors 块中因为vendors 块已经包含它）。
   2. vendors 块被标记为 entry 块，而 entry1 和 entry2 块未被标记为 entry。
4. 最后，由于vendors 块是entry 块，它包含运行时和jquery/jquery_plugin 模块。

案例 3：

1. 有 3 个 entry 块（entry1、entry2 和 vendors）。
2. 配置将vendors块和manifest块设置为通用块。
3. 插件创建manifest 块，因为它不存在。
4. 插件处理vendors公共块：
   1. 它收集在其他块中多次使用的模块：entry1 和 entry2 使用 jquery，因此模块从这些块中删除（注意它没有添加到 vendors 块中因为vendors 块已经包含它）。
   2. vendors 块被标记为 entry 块，而 entry1 和 entry2 块未被标记为 entry。
5. 插件处理manifest公共块（由于块不存在，所以创建）：
   1. 它收集在其他块中多次使用的模块：因为没有模块被多次使用，所以没有模块被移动。
   2. manifest 块标记为 entry 块，而 entry1、entry2 和 vendors 未标记为 entry。
6. 最后，由于 manifest 块是 entry 块，它包含运行时。

希望对你有帮助。