问webpack常用块插件与webpack dll插件

EN

很抱歉给出了很长的答案，但希望它能让事情变得更清楚。

CommonsChunkPlugin原理

项目作者定义了许多应用程序入口点，每个入口点将产生一个包。典型的例子是供应商、多填充、主，但例如，您的应用程序可以在几个独立的“区域”中分离，这些“区域”可以单独加载(例如登录、主、设置)。

然后，项目作者定义了其中的一个包，或者一个单独的包，应该包含所有这些包的公共代码。这是一个绝妙的第三方库和您自己在所有入口点上共享的实用程序。

然后，插件负责分析和收集这些公共代码，然后将其放入定义的包中。每次启动新构建时，所有这些分析和工作都会一次又一次地发生，并且--在监视模式下--当您修改共享代码时，这些代码恰好落入了公用包中。

这样的拆分对于开发构建和生产构建都是有用的。但是对于dev环境，让我们简单地说，重新构建与供应商和复合填充相关的代码可能需要相当长的时间，当您没有真正更改这些部分时(假设您所依赖的第三方代码大于您自己的代码库)，这可能是一种浪费。

DllPlugin原理

例如，在相同的环境下，项目作者创建了两个 webpack配置，其中曾经有一个配置。这个插件可以应用于生产环境，尽管可以说DllPlugin在开发中更有意义(见下文)。

首先，webpack需要对所谓的DLL进行构建配置，这些配置与前面看到的公共代码有点接近，但不完全是这样。据我所知，DLL大多倾向于分组第三方代码(供应商和多填充)，而不是您自己的共享实用程序代码，但这还是一种印象，而不是一条严格的规则。无论如何，这里的项目作者应该分组代码，这些代码在正常开发会话中更改的频率要低得多。在dev环境中，我们的想法是每隔一段时间运行此构建，例如，当依赖项发生变化时。通常，当s/他认为需要时，由开发人员启动这个构建。

另一个webpack构建配置是项目自己的代码所需要的，或者不管怎么说，在开发工作中经常更改的代码。这是开发人员将一次又一次运行的实际构建，或者将在监视模式下运行，与CommonsChunk场景中的单个构建相比，在这一点上应该要快得多。

所以，总而言之，它们看起来很相似，但它们让你击中了不同的目标。因此，您可以考虑在开发环境中使用DllPlugin (优点:编译时间短)，而在生产中使用CommonsChunkPlugin (优点:应用程序更改时的加载时间短)。同样，您也可以在生产中使用DllPlugin，这会给您在一行中运行两个版本带来小小的不便:一个用于DLL，另一个用于应用程序。

HTH

你用一个或另一个。这是一篇文章，它描述了如何在页面底部使用DllPlugin，您可以看到完成相同任务的其他方法。它告诉你什么是不同的，以及利弊。这应该能让你开始。

我也在这里寻找不同之处，但我真的不认为是这样的。至少现在不是了。

如果您查看代码分裂库的webpack文献，它会提到一种提取类似清单文件的方法。根据我的理解，这就是DllPlugin正在做的事情，只不过CommonsChunkPlugin稍微隐含了一些。

好处是您不需要为这类功能维护多个Webpack配置。