爲何一樣的配置別人能夠提升效率，你反而下降了

背景

筆者最近發現本地打包太慢，大概須要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不起做用，找到這個緣由以後，處理起來就很簡單了。就把打包時間去掉就行了。

效果

第一次打包時間以下： 第二次打包時間以下：

結語

通過這一次的失誤以後仍是讓本身成長許多，並非每一次百度好的一些優化配置都適用於自身系統，可能自身系統自己就有一些有害的配置會使得其餘人的優化作無用功