Step14.Webpack构建项目进一步优化
webpack dll VS external
webpack在打包后，生成的文件主要分为三种类型：
* 业务代码
* 外部依赖库
* webpack runtime
webpack中的dll和external在本质上其实是解决的同一个问题：避免将某些外部依赖库打包进我们的业务代码，而是在运行时提供这些依赖。
一方面实现了代码拆分，以及依赖的复用，另一方面提升构建速度.
这两种方案应该是各有各的优劣，分别适用于不同的环境。
(1) dll与externals的区别
dll 符合前端模块化的要求
webpack配置上稍微复杂一些，需要预打包所需的dll资源，并在构建时配置相应的plugin，
使用dll的前提是，这些外部依赖一般不需要发生变更。所以，如果某天发生了变更，那就需要将项目重新构建，违背了dll的使用前提，必然要作出相应的牺牲。
external不太符合前端的模块化思想，所需要的外部库需要在浏览器全局环境下可访问
外部库升级的话，如果兼容之前的API，不需要项目重新构建
webpack配置上稍微简单些，但是同样需要将所需的外部库打包为所需要的格式，并在运行态下引用
相比较而言的话，dll比external应该更加智能一些，主要体现在模块的引用和打包上。比如说如下方式去引用了react中的一个方法：
import AA from 'react/lib/createClass'
如果采用dll的方式，是不会造成重复打包的，他会将引用直接指向dll。但是如果使用external的话，则会react中的部分代码打包进来。
(2) externals
防止将某些 import 的包(package)打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖(external dependencies)。
例如，从 CDN 引入 jQuery，而不是把它打包
<script src="https://code.jquery.com/jquery-3.1.0.js""></script>
module.exports = {
//...
externals: {
jquery: 'jQuery'
}};
这样就剥离了那些不需要改动的依赖模块，换句话，下面展示的代码还可以正常运行：
import $ from 'jquery';
$('.my-element').animate(/* ... */);
DLLPlugin 和 DLLReferencePlugin的使用
DLLPlugin为什么会出现？
在使用webpack进行打包时候，对于依赖的第三方库，比如vue，vuex等这些不会修改的依赖，我们可以让它和我们自己编写的代码分开打包，这样做的好处是每次更改我本地代码的文件的时候，webpack只需要打包我项目本身的文件代码，而不会再去编译第三方库，那么第三方库在第一次打包的时候只打包一次，以后只要我们不升级第三方包的时候，那么webpack就不会对这些库去打包，这样的可以快速的提高打包的速度。因此为了解决这个问题，DllPlugin 和 DllReferencePlugin插件就产生了。
https://www.webpackjs.com/plugins/dll-plugin/#dllplugin
DLLPlugin
DLLPlugin 它能把第三方库代码分离开，并且每次文件更改的时候，它只会打包该项目自身的代码。所以打包速度会更快。
DLLPlugin 这个插件是在一个额外独立的webpack设置中创建一个只有dll的bundle，也就是说我们在项目根目录下除了有webpack.config.js，还会新建一个webpack.dll.config.js文件。webpack.dll.config.js作用是把所有的第三方库依赖打包到一个bundle的dll文件里面，还会生成一个名为 manifest.json文件。
该manifest.json的作用是用来让 DllReferencePlugin 映射到相关的依赖上去的。
DllReferencePlugin 这个插件是在webpack.config.js中使用的，该插件的作用是把刚刚在webpack.dll.config.js中打包生成的dll文件引用到需要的预编译的依赖上来。什么意思呢？就是说在webpack.dll.config.js中打包后比如会生成 vendor.dll.js文件和vendor-manifest.json文件，vendor.dll.js文件包含所有的第三方库文件，vendor-manifest.json文件会包含所有库代码的一个索引，当在使用webpack.config.js文件打包DllReferencePlugin插件的时候，会使用该DllReferencePlugin插件读取vendor-manifest.json文件，看看是否有该第三方库。vendor-manifest.json文件就是有一个第三方库的一个映射而已。
所以说 第一次使用 webpack.dll.config.js 文件会对第三方库打包，打包完成后就不会再打包它了，然后每次运行 webpack.config.js文件的时候，都会打包项目中本身的文件代码，当需要使用第三方依赖的时候，会使用 DllReferencePlugin插件去读取第三方依赖库。所以说它的打包速度会得到一个很大的提升。
DLLPlugin 和 DLLReferencePlugin 用某种方法实现了拆分 bundles，同时还大大提升了构建的速度。
(1) 配置webpack.dll.config.js:
var path = require("path");
var webpack = require("webpack");
var SRC_PATH = path.resolve(__dirname,'./src');
module.exports = {
// 要打包的模块的数组
entry: {
vendor: ['vue/dist/vue.esm.js','vue-router']
},
output: {
path: path.join(__dirname, './static/dll), // 打包后文件输出的位置
filename: '[name].dll.js',// vendor.dll.js中暴露出的全局变量名。
library: '[name]_library' // 与webpack.DllPlugin中的`name: '[name]_library',`保持一致。
},
plugins: [
new webpack.DllPlugin({
path: path.join(SRC_PATH,'./static/dll/[name]-manifest.json'),
name: '[name]_library',
context: __dirname
}),
]
};
DllPlugin 插件有三个配置项参数如下：
context(可选)： manifest文件中请求的上下文，默认为该webpack文件上下文。
name: 公开的dll函数的名称，和 output.library保持一致。
path: manifest.json 生成文件的位置和文件名称。
上面就是webpack.dll.conf.js的主要配置。执行之后会在static文件夹（在vue-cli生成的项目中用于存放不需要webpack构建的静态文件【@vue/cli中的目录名为Public】）下生成两个文件夹（lib文件夹和mainfest文件夹）。其中lib下的文件为我们已经打包好的组件库，mainfest下的文件在引入项目时有用（是一个JSON文件）。
在package.json的scripts里加上：
"dll": "webpack --config webpack.dll.config.js",
运行npm run dll 在static下生成dll文件夹,dll文件夹里包括js文件和json文件
(2) 在webpack.base.conf.js里加上：
// 添加DllReferencePlugin插件
plugins: [
new webpack.DllReferencePlugin({
context: __dirname,
manifest: require('./static/dll/vendor-manifest.json')
})
],
DllReferencePlugin项的参数有如下：
context: manifest文件中请求的上下文。
manifest: 编译时的一个用于加载的JSON的manifest的绝对路径。
mainfest: 请求到模块id的映射(默认值为 manifest.content)
name: dll暴露的地方的名称(默认值为manifest.name)
scope: dll中内容的前缀。
sourceType: dll是如何暴露的libraryTarget。
(3) 在index.html中引入vendor.dll.js：
由于动态链接库我们一般只编译一次，除非依赖的三方库更新，之后就不用编译，因此入口的 index.js 文件中不包含这些模块，所以要在 index.html 中单独引入。
① 第一种方式， 一种是根据打包的路径手动添加
<div id="app"></div><script src="./static/js/vendor.dll.js"></script>
② 第二种方式，用add-asset-html-webpack-plugin或者html-webpack-include-assets-plugin插入到html中，简单自动化
下面着重讲下add-asset-html-webpack-plugin与html-webpack-include-assets-plugin插件的使用，项目中使用add-asset-html-webpack-plugin
安装大同小异
npm安装：
npm install add-asset-html-webpack-plugin -D
npm install html-webpack-include-assets-plugin -D
Yarn安装：
yarn add add-asset-html-webpack-plugin -D
yarn add html-webpack-include-assets-plugin -D
l add-asset-html-webpack-plugin的使用
const AddAssetHtmlPlugin = require('add-asset-html-webpack-plugin');
module.exports = {
...,
plugins: [
...,
# 给定的 JS 或 CSS 文件添加到 webpack 配置的文件中，并将其放入资源列表 html webpack插件注入到生成的 html 中。
new AddAssetHtmlPlugin([
{
# 要添加到编译中的文件的绝对路径
filepath: path.resolve(__dirname,'./static/dll/dll_vendor.js'),
outputPath: 'dll',
publicPath: 'dll',
includeSourcemap: false
}
])
]
}
l html-webpack-include-assets-plugin的使用
const HtmlWebpackIncludeAssetsPlugin = require('html-webpack-include-assets-plugin');
module.exports = {
...,
plugins: [
...,
// 给定的 JS 或 CSS 文件添加到 webpack 配置的文件中，并将其放入资源列表 html webpack插件注入到生成的 html 中。
new HtmlWebpackIncludeAssetsPlugin(
{
assets: ['dll/asset.dll.js','dll/vendor.dll.js'],
append: false
}
)
]
至此，配置之后的：
可以看到npm run build后的时间大幅度减少，在dist打包体积上也比之前的小。在项目优化中，可以很大程度上加快项目的构建速度和减少项目的打包体积。
使用 happypack 提升 Webpack 项目构建速度
提示：由于HappyPack 对file-loader、url-loader 支持的不友好，所以不建议对该loader使用。
webpack打包哪一步最耗时？可能要数loader对文件的转换操作了，我们前面说过，我们使用loader将文件转换为我们需要的类型，文件数量巨大，webpack执行又是单线程的，转换的操作只能一个一个的处理，不能多件事一起做。
我们需要Webpack 能同一时间处理多个任务，发挥多核 CPU 电脑的威力，HappyPack 就能让 Webpack 做到这点，我们将需要通过loader处理的文件先交给happypack去处理，happypack 在收集到这些文件的处理权限后，统一分配CPU资源.
happypack工作原理
happypack 通过new HappyPack(),去实例化一个HappyPack对象，其实就是告诉Happypack核心调度器如何通过一系列loader去转换一类文件，并且可以指定如何为这类转换器作分配子进程。
核心调度器的逻辑代码在主进程里，也就是运行webpack的进程中，核心调度器会将一个个任务分配给当前空闲的子进程，子进程处理完后会将结果发送给核心调度器，它们之间的数据交换是通过进程间的通讯API实现的。
核心调度器收到来自子进程处理完毕的结果后，会通知webpack该文件已经处理完毕
参考：https://www.qdtalk.com/2018/11/16/webpack4plugin-2/
安装：
yarn add happypack --dev
使用：
// 引入 happypack
const HappyPack = require('happypack');
// 创建 happypack 共享进程池，其中包含 6 个子进程
const happyThreadPool = HappyPack.ThreadPool({ size: 6 });
module.exports = {
//省略部分配置
module: {
rules: [
{
test: /.js$/,
//把对.js 的文件处理交给id为happyBabel 的HappyPack 的实例执行
use: 'happypack/loader?id=happyBabel',
//排除node_modules 目录下的文件，合理的使用排除可以事半功倍
exclude: path.resolve(__dirname,'node_modules')
},
]
},
plugins: [
new HappyPack({
//用id来标识 happypack处理那里类文件
id: 'happyBabel',
//如何处理js文件 用法和loader 的配置一样
loaders: [{
loader: 'babel-loader?cacheDirectory=true',
}],
//使用共享进程池中的自进程去处理任务
threadPool: happyThreadPool,
//允许 HappyPack 输出日志，默认为true
verbose: true,
})
]
}
在 Loader 配置中，所有文件的处理都交给了 happypack/loader 去处理，使用紧跟其后的 querystring ?id=babel 去告诉 happypack/loader 去选择哪个 HappyPack 实例去处理文件。
在 Plugin 配置中，新增了两个 HappyPack 实例分别用于告诉 happypack/loader 去如何处理 .js 和 .css 文件。选项中的 id 属性的值和上面 querystring 中的 ?id=babel 相对应，选项中的 loaders 属性和 Loader 配置中一样。
对应的参数
id：String
用唯一的标识符 id 来代表当前的 HappyPack 是用来处理一类特定的文件.
loaders: Array
用法和 webpack Loader 配置中一样.
threads: Number
代表开启几个子进程去处理这一类型的文件，默认是3个，类型必须是整数。
verbose: Boolean
是否允许 HappyPack 输出日志，默认是 true。
threadPool: HappyThreadPool
代表共享进程池，即多个 HappyPack 实例都使用同一个共享进程池中的子进程去处理任务，以防止资源占用过多。
verboseWhenProfiling: Boolean
开启webpack --profile ,仍然希望HappyPack产生输出。
debug: Boolean
启用debug 用于故障排查。默认 false。
https://blog.csdn.net/zgd826237710/article/details/88172290#_HappyPack_36
注意
注意，webpack4中的happypack要使用5.0.0版本，如果你是从webpack3升级到webpack4，记得升级happypack
上面的loader中出现一个陌生词cacheDirectory：
cacheDirectory默认值为 false。
当有设置时，指定的目录将用来缓存 loader 的执行结果。之后的 webpack 构建，将会尝试读取缓存，来避免在每次执行时，可能产生的、高性能消耗的 Babel 重新编译过程(recompilation process)。如果设置了一个空值 (loader: ‘babel-loader?cacheDirectory’) 或者 true (loader: babel-loader?cacheDirectory=true)，loader 将使用默认的缓存目录 node_modules/.cache/babel-loader，如果在任何根目录下都没有找到 node_modules 目录，将会降级回退到操作系统默认的临时文件目录。