在我使用 webpack common chunks 插件创建包含第三方库（如 angular、react、lodash 等）的供应商包之前，但后来我知道了 webpack dll 插件。他们似乎做同样的事情，但 dll 插件也可以让你减少构建时间。所以我很困惑我是否需要同时使用这两个插件。我应该使用通用块插件在生产构建中创建供应商包，并在开发构建中使用 dll 插件。或者我应该在生产和开发版本中使用 dll 插件？你能解释一下吗？
问问题
8952 次
3 回答
35
对不起，答案很长，但我们希望它可以帮助使事情更清楚。
CommonsChunkPlugin 基本原理
项目作者定义了许多应用程序入口点，每个入口点都会生成一个包。典型的例子是vendor、polyfills、main，但例如，您的应用程序可以拆分为几个独立的“区域”，以便单独加载（例如登录、main、设置）。
然后，项目作者定义这些捆绑包中的哪一个或单独的捆绑包应该包含所有这些捆绑包共有的代码。这通常是第 3 方库和您自己的跨所有入口点的共享实用程序。
然后插件负责分析和收集这些公共代码，然后将其放入定义的包中。每次您开始新构建时，所有此类分析和工作都会一次又一次地发生，并且 - 在监视模式下 - 当您修改共享的代码并且碰巧落入公共捆绑包时。
这种拆分对于开发构建和生产构建都很有用。但是对于开发环境，我们只是说重新构建与供应商和 polyfills 相关的代码可能需要相当长的时间，而且当您没有真正更改这些部分时，这可能是一种浪费（假设您依赖的第 3 方代码大于您的自己的代码库）。
DllPlugin 基本原理
给定相同的环境，例如开发，项目作者创建了两个webpack 配置，而以前只有一个。该插件可以应用于生产环境，尽管可以说 DllPlugin 在开发中更有意义（见下文）。
所谓的DLL需要第一个 webpack 构建配置，它有点接近于之前看到的公共代码，但不完全一样。据我了解，DLL 大多倾向于对第 3 方代码（供应商和 polyfill）进行分组，而不是您自己的共享实用程序代码，但这也是一种印象，而不是严格的规则。无论如何，这里的项目作者应该对在正常开发会话期间更改频率较低的代码进行分组。在开发环境中，这个想法是每隔一段时间运行一次这个构建，例如当依赖项发生变化时。通常由开发人员在他/她认为需要时触发此构建。
项目自己的代码，或者在进行开发工作时定期更改的任何代码都需要其他 webpack 构建配置。这是开发人员将一次又一次地运行或以监视模式运行的实际构建，此时它应该比在 CommonsChunk 场景中看到的单个构建要快得多。
所以，总而言之，它们看起来很相似，但它们让你击中不同的目标。这么多，您可以考虑将 DllPlugin 用于您的开发环境（优点：编译时间短），同时使用 CommonsChunkPlugin 进行生产（优点：应用程序更改时的加载时间短）。同样，您也可以在生产环境中使用 DllPlugin，但会带来一些不便，即必须连续运行两个构建：一个用于 DLL，下一个用于应用程序。
高温高压
于 2017-05-09T17:12:14.070 回答
11
您使用其中一种。这是一篇文章，描述了如何使用 DllPlugin，在页面底部您可以看到完成相同任务的替代方法。它告诉你有什么区别以及优点和缺点。这应该让你开始。
于 2017-02-01T20:38:32.793 回答
4
我也在这里寻找不同之处，但我真的不认为是这种情况。至少，现在不是了。
如果您查看代码拆分库的webpack 文档，它会提到一种提取类似清单文件的方法。据我了解，这就是 DllPlugin 正在做的事情，只是它在 CommonsChunkPlugin 中更加隐含。
好处是您不需要为此类功能维护多个 Webpack 配置。
于 2017-03-29T04:40:56.933 回答