为何一样的配置别人能够提升效率，你反而下降了

背景

笔者最近发现本地打包太慢，大概须要3分钟左右，因而在网上找了百度了下 发现就是2个点

• dll
• hard-source-webpack-plugin

看了下文章就说用了hard-source-webpack-plugin以后能提高 90% 的构建速度，因而乎我满心欢喜的用上了了，发现第一次构建3分半，，第二次 仍是3分半 ，因而乎我就好奇，为何呢？？

因为公司的内网不能上掘金,也不能发表文章，因此笔者是在家里研究这个问题的，项目也是网上随便找的。因此实际的数据可能和真正的公司的项目有误差，可是此文章的目的只是引导你们遇到问题的时候如何去思考以及解决他

本文章分析的源码是基于@vue/cli 4.5.11建立的都是默认配置,代码不重要，重要的是分析的过程

分析

一直以来计时都是用手机计时，那么我是否是须要一个工具来帮我计算这个时间，能够用speed-measure-webpack-plugin可是时间信息不是在最后一行输出，为了方便看时间，那么就本身写一个计算打包时间的webpack插件CountTimePlugin

统计webpack打包时间插件CountTimePlugin

这个插件的编写逻辑就是利用webpack的stats的endTime和startTime作一个减法就出来了打包时间

// CountTimePlugin.js
module.exports =  class CountTimePlugin {
  constructor() {}

  apply(compiler) {
    compiler.hooks.done.tap("ConsoleTime", stats => {
      const times = stats.endTime - stats.startTime;
      const minute = Math.floor(times / 1000 / 60);
      const second = Math.floor(times / 1000 - minute * 60);
      setTimeout(() => {
        console.log(
          "the build time:\n" + minute + " minute , " + second + " second \n"
        );
      },2000)
    });
  }
}
复制代码

使用统计时间插件

连续打了2次包发现时间都是27 秒左右，查看了一下speed-measure-webpack-plugin打包的日志都是以下

首先2次打包之间我是没有对代码进行修改的，那么cache-loader没有生效？

检查是否启用了cache-loader

使用 vue inspect > projectConfig.txt 查看这个配置文件咱们能够发现.vue文件和test: /\.m?jsx?$/,的文件都是用cache-loader的

这个时候思路就有点乱了有使用cache-loader为何没有换成呢？这个时候脑壳中忽然想到每次打包都有hash难不成不同？这个想法一会儿就好像打开了通往成功的大门

检查cache-loader的hash

我有一次的再命令行输入vue inspect > projectConfig2.txt

对比了一下 发现cacheIdentifier 真的不同，为何呢？

定位问题

如何调试

调试的方法有不少，好比装一个debugger-for-chrome,可是笔者仍是喜欢用编辑器调试代码，控制台新建一个JavaScript Debug Terminal 输入

node ./node_modules/@vue/cli-service/bin/vue-cli-service.js build
复制代码

找到cacheIdentifier在哪里生成的

咱们的入口文件是node_modules/@vue/cli-service/bin/vue-cli-service.js

// 刚开始是一个构造器，第32行调用了一个生成插件的方法
this.plugins = this.resolvePlugins(plugins, useBuiltIn)

// 142行 
resolvePlugins（）{
    const idToPlugin = id => ({
      id: id.replace(/^.\//, 'built-in:'),
      apply: require(id)
    })

    let plugins

    const builtInPlugins = [
      './commands/serve',
      './commands/build',
      './commands/inspect',
      './commands/help',
      // config plugins are order sensitive
      './config/base',
      './config/css',
      './config/prod',
      './config/app'
    ].map(idToPlugin)
    
    //... 省略
    // 看了下builtInPlugins数组中的文件，其中./config/base 就是生成vue-loader cache-loader配置的地方
    
    // ctrl+f 搜一下plugins 就能看到 init方法中有使用
    
      // apply plugins.
    this.plugins.forEach(({ id, apply }) => {
      if (this.pluginsToSkip.has(id)) return
      apply(new PluginAPI(id, this), this.projectOptions)
    })
    
    // 再打断点能够知道 执行的是node_modules/@vue/cli-service/lib/commands/build/index.js的方法
}
复制代码

咱们在 node_modules/@vue/cli-service/lib/commands/build/index.js 第三个参数中增长断点得知，最后调用的是 node_modules/@vue/cli-service/lib/commands/build/resolveAppConfig.js的方法，

到这里终于回去了。咱们回到 service.js 再继续断点能够跳转到node_modules/@vue/cli-service/lib/PluginAPI.js的genCacheConfig方法

调试genCacheConfig

经过前面的步骤咱们能够得知，咱们总算找到了生成cacheIdentifier的地方就是在genCacheConfig中

const cacheIdentifier = hash(variables)
复制代码

经过这段代码能够知道 惟一的变量就是variables

const variables = {
      partialIdentifier,
      'cli-service': require('../package.json').version,
      'cache-loader': require('cache-loader/package.json').version,
      env: process.env.NODE_ENV,
      test: !!process.env.VUE_CLI_TEST,
      config: [
        fmtFunc(this.service.projectOptions.chainWebpack),
        fmtFunc(this.service.projectOptions.configureWebpack)
      ]
    }
复制代码

因而咱们看一下咱们项目的webpack配置

const childProcess = require('child_process')
// 分支名 由于平安都是标装机自带全局的git工具
const branch = childProcess.execSync('git rev-parse --abbrev-ref HEAD')


configureWebpack: {
    plugins: [
      new CountTimePlugin(),
      new webpack.BannerPlugin(`分支名： ${branch}, 打包时间： ${new Date().toLocaleString()}`),
      new HardSourceWebpackPlugin()
    ],
  },
复制代码

就能够发现 咱们的项目用了一个bannerPlugin，由于项目都是本地打包，会有多个版本并行，而后只有一个环境，会发生抢环境的问题，因而我就把全部的静态资源，加一个日志 把git分支名，以及打包时间打包到静态资源中了，这样能够解决开发人员快速辨别当前的测试环境的代码是哪一个分支的，没想到随手增长的打包时间反而致使了hard-source-webpack-plugin不起做用，找到这个缘由以后，处理起来就很简单了。就把打包时间去掉就行了。

效果

第一次打包时间以下： 第二次打包时间以下：

结语

通过这一次的失误以后仍是让本身成长许多，并非每一次百度好的一些优化配置都适用于自身系统，可能自身系统自己就有一些有害的配置会使得其余人的优化作无用功