详细解释如何在webpack中使用DllPlugin

前言

(时间过得真快，然后我就懒了一个多月)

什么是DLL

动态链接库文件是一个动态链接库文件。在Windows中，许多应用程序不是一个完整的可执行文件。它们被分为一些相对独立的动态链接库，即DLL文件，它们被放置在系统中。当我们执行某个程序时，会调用对应的DLL文件。比如很多产品使用螺丝，但是工厂生产不同的产品时，不需要每次都一起生产螺丝，因为螺丝可以单独生产，用于多种产品。这里螺丝的作用可以理解为dll。

为什么使用dll

一般来说，我们的代码至少可以简单地分为业务代码和第三方库。如果不这样做，每次构建时都需要重新构建一次所有的代码，这需要很多时间。然后，在大多数情况下，许多第三方库的代码不会改变(除非版本升级)。此时可以使用dll:将可重用性更高的第三方模块打包到动态链接库中。不升级这些库，动态库就不需要重新打包，每次构建时只重新打包业务代码。

还是上面的例子：把每一个构造都当成生产产品的过程，我们先提取生产螺丝的过程，然后不管调整产品的功能还是设计(对应业务代码的变化)，都不用重复生产螺丝(第三方模块不需要重复打包)；除非产品需要使用新型号的螺丝(第三方模块需要升级)，否则需要重新生产新的螺丝，然后可以重点调整产品本身。

基本用法

使用dll时，构建过程可以分为dll构建过程和主构建过程(这是本质)，所以需要两个构建配置文件，比如webpack.config.js和webpack.dll.config.js

1.使用DLLPlugin将需要分离的模块打包到动态库中

DllPlugin是webpack的内置插件，webpack.dll.config.js文件直接配置，无需额外安装：

Module.exports={=entry: {//第三方库react :[' react '，' react-DOM '，' react-reduce']}，output : {//输出动态链接库的文件名，[name]代表当前动态链接库的名称。文件名： '[名称]。dll.js '，path3360 resolve ('dist/dll ')，//library必须与以下dllplugin中的名称一致。稍后将描述库：“[name]_ dll _[hash]”}。Plugins: [//访问DLL插件NewWebPack。DLL Plugin({//动态链接库的全局变量名，需要和output.library//The值一致这个字段是输出manifest.json文件中的name字段的值，name3360' [name] _ dll _ [hash]'。//描述文件名path : path . join(_ dirname，' dist/dll '，'[name]。manifest.json')}当输出动态链接库的manifest.json文件时。]}我们来看看这一步做了什么。执行：web pack-config web pack . dll . config，然后转到指定的输出文件夹查看输出：

react.dll文件是数组保存的模块，索引值作为ID；react.manifest.json文件用于描述保存在相应dll文件中的模块中刚刚构建的所有模块，如下所示：

{ ' name ' : ' react _ dll _ 553 e24 e2c 44987d 2578 f '，' content':{ '。/node _ modules/web pack/node _ modules/process/browser . js ' : { ' id ' :0，' meta':{}，'。/node _ modules/react/node _ modules/fbjs/lib/不变量. js':{'id':1，' meta':{}，/node _ modules/react/lib/object . assign . js ' : { ' id ' :2，' meta' : {}，'。/node _ modules/react/node _ modules/fbjs/lib/warning . js '

要在webpack.config中使用dll，需要使用DllReferencePlugin。该插件通过引用dll的清单文件将依赖名称映射到模块id，然后在必要时通过内置的webpack_require函数来要求它们。

Newwebpack。dllreference插件({context: _ _ dirname，manifest : require('。/dist/dll/react . manifest . JSON ')})，这里使用第一步生成的清单文件。给出主要的构造过程作为查找dll的基础：DllReferencePlugin从manifest.json文件中读取name字段的值，从全局变量中获取动态链接库的内容时，将该值的内容作为全局变量名。因此，在webpack_dll.config.js文件中，DllPlugin中的name参数必须与output.library中的一致.

3.在入口文件中引入dll文件。

生成的dll公开了全局函数，所以需要在入口文件中引入相应的dll文件。

body div id='app'/div！-引用dll文件-脚本src=' http:/./dist/dll/react . dll . js '/脚本/正文

首先，从前面的介绍中，至少可以看出dll的两个功能

单独的代码、业务代码和第三方模块可以打包到不同的文件中，这有几个优点：

避免打包的单个文件太大，不利于调试。将单个大文件拆分成多个小文件后，在一定情况下有利于加载(在不超过浏览器一次请求文件数的情况下，并行下载肯定比串行下载快)，提高了构建速度。当第三方库没有变化时，因为我们只构建业务相关的代码，自然比完全重建要快得多。

需要注意的事项

我们可以从前面看到dll带来的好处，但这并不意味着我们应该把除业务代码之外的所有代码都扔进dll，比如：1。对于像lodash这样的第三方库，正确的用法是只导入所需的函数(使用要引用的内容)，例如：

//正确用法从' lodash/isplayanobject '/导入isplayanobject从' lodash '导入{ isplainobject }不正确用法。这两种编写方法的区别在于，在打包的时候，webpack会根据引用来打包依赖的内容，所以在第一次编写的时候，webpack只会打包lodash的isplainobject库，而在第二次编写的时候，它会打包整个lodash。现在假设项目中不同的模块只使用了lodash中的一些函数，某个函数没有被多次重用，那么在dll中加入lodash带来的好处并不明显，反而导致了两个问题：

由于整个lodash都是打包的，打包文件的总大小(注意总大小)比原始文件大，在dll中打包太多内容需要时间。虽然我们一般都是在第三方模块更新后才重新编译(也就是dll打包的过程)，但是如果这个时间太长，体验不好，就要进行实践和反思。

让我们在一个相对较大的项目中单独使用dll后获得利润。提取的内容是与react和fish组件相关的第三方库。施工时间从120秒减少到80秒左右(当然这个时间还是有点吓人的)。施工前appjs大小为680kb。拆分后的业务代码和第三方代码分别为400kb和380kb(这是一个拆分后的大小比拆分前大的例子)。从这个角度来看，可能很清楚常见的第三方库是否应该放入dll中(比如react系列打包肯定不是损失)，但还是有一些需要根据具体的项目内容来判断和选择。(强烈建议使用webpack-bundle-analyzer插件进行性能分析)

摘要

本文介绍了Dllplugin的思想、基本用法和应用场景(更多使用细节见官方文档)。结合一些个人的实践经验，或许可以明确常见的第三方库是否应该放入dll(比如react系列打包肯定不是亏)，但有些要根据具体的项目内容来判断。例如，我上面的实际例子表明，电流分流不够好。也欢迎大家一起讨论这一块。

以上就是本文的全部内容。希望对大家的学习有帮助，支持我们。