从零开始基于webpack4 babel8搭建vue开发环境（四）

上一节我们增加了一些高级特性的配置，地址
这一节，我们主要对构建性能进行优化，，

首先，我们祭出构建性能优化最强的工具，DllReferencePlugin，DllPlugin，
这个插件的主要功能是，对一些大的，不会经常变动的包，进行提前构建，打包出一个对某些模块的映射文件和那些模块的构建结果，然后在我们开发构建时，当引入那些包时，直接通过映射文件找到对应的打包好的文件而不需要再次打包，大大降低了构建速度，
简单点说，就是提前打包好部分文件，

当你的项目依赖的变动小的文件很多时，这个方案可以是你的构建速度提高几个数量级，非常明显，下面我们来介绍下插件的使用方法

这个插件是webpack自带，不需要额外安装，我们先额外创建一个配置文件，用来作为提前构建的配置文件，webpack.dll.js

const path = require('path');
const VueLoaderPlugin = require('vue-loader/lib/plugin')
const webpack = require("webpack")

module.exports = {
  entry: {
      vendor:[
          "vue",
          "vue-router"
      ]
    },
  output: {
    path: path.resolve(__dirname, 'static/js'),
    filename: '[name].dll.js',
    library:'[name]'
  },
  module:{
    rules:[
      {
        test: /\.vue$/,
        use:["vue-loader"]
      },
      {
        test:/\.js$/,
        use:["babel-loader"]
      },

    ],
  },
  plugins:[
    new VueLoaderPlugin(),
    new webpack.DllPlugin({
        path: path.join(__dirname, 'static/js', '[name]-manifest.json'),
        name:"[name]"
      })
  
  ]
}

需要提前构建的包，都可以放在entry下vendor数组里，本例只引入了这两个不需要变动的文件，顺便贴下我们公司依赖的不需要变动文件

可以看到，如果开发环境下少打包这么多文件，带来的构建上的性能提升是巨大的。
我们在package.json中增加一个脚本专门用来打包提前构建的文件

"dll": "webpack --config webpack.dll.js"

按照上方配置文件，执行npm run dll 打包出一个vendor.dll.js和vendor-manifest.json文件到static/js文件夹下。
这时候，提前打包的文件已经打包好，我们可以通过任何方法把它引入到html文件中，我们通过最简单的方式，直接通过script标签，提前把它引入到index.html中

<script src="./static/js/vendor.dll.js"></script>

提前打包的文件已经打包好，映射文件也已经产生，这时，我们需要到webpack构建入口文件配置DllReferencePlugin插件来应用配置文件从而略过对已打包文件的打包过程

new webpack.DllReferencePlugin({
        context: __dirname,
        manifest: require("./static/js/vendor-manifest.json"),
      })

配置完成，
配置提前打包后，本例中，main.js大小为487kb，构建时间为2500ms，配置前main.js大小为790kb，构建时间为3400ms，可以看到，直接减少了一半的体积，一半的时间，性能提升非常明显。

接下来，我们介绍提升构建性能的第二个有力工具，SplitChunksPlugin
在webpack4中，CommonsChunkPlugin已经被移除，替换为SplitChunksPlugin，这个插件可以用于多页面应用公共模块的抽取和懒加载公共模块的抽取，本例中我们是一个单页面应用，但是用到了路由懒加载，当有很多路由时，SplitChunksPlugin带来的构建性能的提升也是非常明显的。
SplitChunksPlugin也是webpack4内置的插件，

optimization: {
    splitChunks: {
      name:'common',
      minSize:1,
      minChunks:1,
      maxAsyncRequests:10,
      chunks:'async'
    },
  },

把chunks设置为async 表示只对懒加载的文件进行分割，minSize表示进行分割的最小体积，minChunks表示进行分割的模块最小引入次数，maxInitialRequests表示入口文件不能同时懒加载文件的最高数量，如果超过就不进行分割，name表示分割后的名字，

然后我们在本例中额外增加两个懒加载路由

import VueRouter from "vue-router"

export default new VueRouter({
    routes:[
                {   
                    name:'routercomp',
                    path:'/',
                    component:() => import("../components/routercomp.vue")
                },
                {   
                    name:'routercomp2',
                    path:'/2',
                    component:() => import("../components/routercomp2.vue")
                },
                {   
                    name:'routercomp3',
                    path:'/3',
                    component:() => import("../components/rout.vue")
                }
            ]
})

每个路由都引入一个dict模块中的a变量

dict.js

export   var a = 1

模块routercomp.vue，其他模块类似

import {a} from "../static/lib/dict.js"

三个模块都引入了dict模块中的a变量，我们npm run dev进行打包，

可以看到，打包出五个js文件，包括三个懒加载的路由文件，一个提取出的common文件，一个主入口main.js文件，三个路由文件中的公用模块dict被打包到了common里，避免了每个路由都重复dict模块，降低了最终文件的大小，也降低了构建的速度。

接下来我们介绍下多进程打包

webpack4之前我们经常使用happypack进行多线程打包，充分利用多核cpu，然而，happypack的维护者，已经不在维护他，

Maintenance mode notice
My interest in the project is fading away mainly because I'm not using JavaScript as much as I was in the past. Additionally, Webpack's native performance is improving and (I hope) it will soon make this plugin unnecessary.
See the FAQ entry about Webpack 4 and thread-loader.
Contributions are always welcome. Changes I make from this point will be restricted to bug-fixing. If someone wants to take over, feel free to get in touch.
Thanks to everyone who used the library, contributed to it and helped in refining it!!!

并且，在webpack4上使用happypack和作者推荐的thread-loader并没有明显的性能提升，所以这两个插件大家慎用，（怀疑webpack4已经内置多线程，单为找到证据）

接下来我们介绍下对于一些耗时loader的优化

首先是babel-loader非常耗时，因为无论是我们的工具js文件还是.vue中的script文件，最后都是会被babel-loader处理，所以对这个loader进行优化还是很有必要的，最简单的优化方式便是为babel-loader添加cacheDirectory属性

{
        test:/\.js$/,
        use:["babel-loader?cacheDirectory=true"]
      },

添加缓存属性后，babel-loader的处理速度能够提高2倍，在本例中，我们的启动速度提高了两倍以上。

对于其他的一些耗时loader我们可以使用cache-loader，对那些耗时loader进行缓存处理，但在本例中，没有明显提升，慎重使用。

最后介绍下webpack4 提供的模式配置

通过对mode的配置，webpack4会进行一些内置的优化，这也是在向配置简单看齐，两种模式webpack内置的优化如下

development
会将 process.env.NODE_ENV 的值设为 development。启用 NamedChunksPlugin 和 NamedModulesPlugin。

production
会将 process.env.NODE_ENV 的值设为 production。启用 FlagDependencyUsagePlugin, FlagIncludedChunksPlugin, ModuleConcatenationPlugin, NoEmitOnErrorsPlugin, OccurrenceOrderPlugin, SideEffectsFlagPlugin 和 UglifyJsPlugin.

配置方式

mode:'development',

总结

这一节对webpack配置进行了优化，经过这些优化，无论我们的项目如何复杂，模块如何多，webpack都不会对我们开发效率造成影响，本人实际项目中涉及150多模块，引入众多工具包，经过此配置的优化仍然保持热更新在两秒左右，开发效率未受到任何影响，

下一节我们将对生产环境进行配置，生产环境的需求和开发环境还是很不一样的。

项目源码在这里,看的舒服的话顺便给个star ><