在我使用webpack common chunks插件创建包含第三方库（如angular，react，lodash等）的供应商包之前，然后我知道了webpack dll插件。他们似乎做同样的事情但dll插件也允许你减少构建时间。所以我很困惑我需要将这两个插件一起使用。我应该使用常见的块插件来在生成构建中创建供应商包并在开发构建中创建dll插件。或者我应该在生产和开发构建中使用dll插件？你能解释一下吗？
答案 0 :(得分：30)
对不起，答案很长，但我们希望它能让事情变得更清楚。
项目作者定义了许多将生成捆绑的应用程序入口点。典型的例子是供应商， polyfills ， main ，但是例如你的应用程序可以拆分成几个独立的“区域”，分别加载是有意义的（例如登录，主要，设置）。
然后，项目作者定义哪些捆绑包或单独捆绑包应包含所有捆绑包共有的代码。这是所有入口点的第三方库和您自己的共享实用程序。
然后，插件负责分析和收集这些公共代码，然后将其放入已定义的包中。每次开始新构建时，所有这样的分析和工作都会一次又一次地发生，并且 - 在监视模式下 - 当您修改共享的代码并恰好落入公共捆绑包时。
这种拆分对于开发构建和生产构建都很有用。但是对于开发环境，我们只是说重建与供应商和polyfill相关的代码可能需要相当长的时间，如果你没有真正改变这些部分，这可能是一种浪费（假设你所依赖的第三方代码大于你的自己的代码库）。
在相同的环境下，例如开发，项目作者创建两个 webpack配置，其中曾经有一个。该插件可以应用于生产环境，虽然可以说DllPlugin在开发中更有意义（见下文）。
所谓的 DLL 需要第一个webpack构建配置，它类似于之前看到的公共代码，但并不完全如此。根据我的理解，DLL主要倾向于将第三方代码（供应商和polyfill）分组，而不是您自己的共享实用程序代码，但这又是一种印象，而不是严格的规则。无论如何，这里的项目作者应该在正常的开发会话期间对更改频率更低的代码进行分组。在开发环境中，这个想法是每隔一段时间运行一次这个构建，例如当依赖项发生变化时。并且通常由开发人员在他/她认为需要时触发此构建。
项目自己的代码需要其他webpack构建配置，或者在开发工作时需要定期更改的代码。这是开发人员一次又一次运行的实际构建，或者将以监视模式运行，此时与CommonsChunk场景中的单一构建相比，它应该非常快。
所以，总而言之，它们似乎相似，但它们让你击中不同的目标。这么多，你可以考虑在开发环境中使用DllPlugin（优点：编译时间短），同时使用CommonsChunkPlugin进行生产（优点：app更改时的加载时间短）。同样，您也可以在生产中使用DllPlugin，只需要连续运行两个版本的小麻烦：一个用于DLL，另一个用于应用程序。
HTH
答案 1 :(得分：10)
您使用其中一个。 Here is an article，它描述了如何使用DllPlugin并在页面底部向下看，您可以看到完成同一事情的替代方法。它告诉您差异是什么以及优缺点。这应该可以帮到你。
答案 2 :(得分：4)
我也在寻找差异，但我真的不认为是这种情况。至少，不再了。
如果您查看代码拆分库的webpack documenation，它会提到一种提取类似清单文件的方法。根据我的理解，这就是DllPlugin正在做的事情，除了CommonsChunkPlugin稍微隐含一些。
好处是您不需要为这种功能维护多个Webpack配置。