在我使用webpack通用块插件创建包含第三方库（例如angular，react，lodash等）的供应商捆绑包之前，但是后来我知道了webpack dll插件。他们似乎做同样的事情，但是dll插件还可以减少构建时间。所以我很困惑我是否需要同时使用这两个插件。我应该在生产版本中使用通用的块插件创建供应商捆绑包，还是在开发版本中使用dll插件。还是在生产和开发版本中都应使用dll插件？你能解释一下吗？
很抱歉，答案很长，但是我们希望它可以使事情变得更清楚。
项目作者定义了许多应用程序入口点，每个入口点都会产生一个捆绑包。典型的示例是vendor，polyfills，main，但是例如，您的应用程序可以分为几个独立的“区域”，这些区域可以单独加载（例如，登录名，main，设置）。
然后，项目作者定义这些捆绑包中的哪个捆绑包或一个单独的捆绑包应包含所有捆绑包共用的代码。通常，这是第三方库和您在所有入口点之间共享的实用程序。
然后由插件负责分析并收集此类通用代码，然后将其放入定义的包中。每当您开始新的构建时，所有这些分析和工作都会一次又一次地发生，并且-在监视模式下-当您修改共享的代码并且碰巧属于commons软件包时。
这样的拆分对于开发构建和生产构建都是有用的。但是对于开发环境，我们只能说重新构建与供应商和polyfill相关的代码可能会花费一些时间，并且当您没有真正更改那些部分时（这可能是浪费的）（假设您所依赖的第3方代码大于您的第3方代码）自己的代码库）。
给定相同的环境（例如开发），项目作者将创建两个 Webpack配置，其中以前是一个。该插件可以应用于生产环境，尽管可以说DllPlugin在开发中更有意义（请参见下文）。
所谓的DLL需要首先进行webpack构建配置，这些DLL与之前看到的commons代码有点相似，但不完全相同。据我了解，DLL通常倾向于将第三方代码（供应商和polyfills）分组，而不是您自己的共享实用程序代码，但这再次给人留下了深刻的印象，而不是严格的规则。无论如何，这里的项目作者应该对在正常开发过程中更改频率不太高的代码进行分组。在开发环境中，该想法是每隔一段时间运行一次此版本，例如，当依赖项更改时。通常，由开发人员在需要时触发此构建。
项目自己的代码或在执行开发工作时会定期更改的代码需要其他webpack构建配置。这是开发人员将一次又一次运行或将在监视模式下运行的实际构建，并且与CommonsChunk场景中看到的单个构建相比，这时它应该快得多。
因此，总的来说，它们看起来很相似，但是它们让您达到了不同的目标。太多了，您可以考虑将DllPlugin用于您的开发环境（优势：编译时间短），而将CommonsChunkPlugin用于生产（优势：应用程序更改时加载时间短）。同样，您还可以在生产环境中使用DllPlugin，这带来的不便之处是必须连续运行两个版本：一个用于DLL，另一个用于应用程序。
高温超导
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句