基於webpack的應用治理

當前市面上大部分前端應用都是基於webpack進行構建，而隨着應用日益龐大，webpack應用就會出現構建速度慢，構建結果體積大等一系列問題。

1.webpack應用治理應該從哪一個方向入手？

隨着應用的不斷迭代，webpack應用最多見的兩個問題就是：

1. 構建速度慢
2. 構建體積大

有一個很簡單的劃分方式，就是以構建（build）爲分界線，分紅前向治理和後向治理：

• 前向治理：提高構建速度
• 後向治理：保證構建結果質量

咱們的治理方向，就是圍繞前向治理和後向治理。

---

2.前向治理包含哪些內容？

前向治理的核心概念，就是一個字 快 ，目的就是提高構建速度，市面上大部分webpack優化文章都是這一類提高構建速度的文章，因此這裏就簡單介紹一些不錯的實踐

2.1 利用SMP採集webpack數據指標

數據先行，經過speed-measure-webpack-plugin採集性能指標，能夠獲得webpack在整個編譯過程當中在loader、plugin上花費的時間，基於該數據能夠專項的進行優化和治理。

2.2 開啓緩存

若是經過SMP分析得知在loader編譯過程耗時較多，那麼能夠在覈心loader，例如babel-loader中添加緩存。

{
  loader: 'babel-loader',
    options: {
      cacheDirectory: true
    }
}
複製代碼

2.3 開啓happyPack多線程編譯

若是經過SMP分析得知在loader編譯過程耗時較多，還能夠經過使用happyPack，開啓多線程編譯，提高開發效率。

2.4 使用dll技術

dll能夠簡單理解成提早打包，例如lodash、echarts等大型npm包，能夠經過dll將其提早打包好，這樣在業務開發過程當中就不用再重複去打包了，能夠大幅縮減打包時間。

2.5 升級到webpack5

webpack5利用 持久緩存 來提升構建性能，或許升級webpack後，前述的各類優化，都將成爲歷史。

---

3. 後向治理包含哪些內容？

後向治理主要保證構建結果的質量

3.1可視化分析構建結果

很常見的就是webpack-bundle-analyzeer，提供打包結果的可視化展現，如上圖給予的決策幫助是：

1. 是否須要按需加載
2. 是否須要提取公共代碼
3. 是否須要制定cacheGroup的策略

3.2 清理deadcode

業務開發過程當中，隨着業務迭代，常常有些文件、模塊及代碼被廢棄，這些廢棄代碼隨着時間推移，將逐漸變爲歷史包袱，因此針對構建後結果，咱們要作的就是清理其中的deadcode。

前面webpack-bundle-analyzeer雖然是最經常使用的插件，但依舊有一些缺陷：

3.2.1. 體積超小的deadcode模塊引用，沒法被準確識別

例如上圖：

• lodash體積大一會兒就能被發現，就會意識到重複引用或者是未使用
• 但deadcode模塊c體積很小，即使被chunk一、chunk2都引用了，也不必定能馬上發現，很容易被帶到線上
• 並且這種deadcode也沒法經過splitchunk來進行優化，由於splitchunk根據引用次數提取公共代碼，沒法分辨是不是廢棄代碼，因此對模塊c.js這種的deadcode就無力了

3.2.2. tree-sharking只保留有用的代碼，但deadcode還在那裏

tree-sharking你們都瞭解，搖掉不須要的代碼，作爲最終的輸出結果，但反過來講，這些廢棄代碼依舊在本地真實不虛的存在着。

因此如何能準確的清理掉deadcode呢？這就須要經過webpack的 統計信息(stats) 來進行更細節的分析

3.3 統計信息(stats)

stats是經過 webpack 編譯源文件時，生成的包含有關於模塊的統計數據的 JSON 文件，這些統計數據不只能夠幫助開發者來分析應用的依賴圖表，還能夠優化編譯的速度。

webpack --profile --json > compilation-stats.json
複製代碼

經過上述全局命令便可輸出統計信息,例如：

{
  "version": "1.4.13", // Version of webpack used for the compilation
  "hash": "11593e3b3ac85436984a", // Compilation specific hash
  "time": 2469, // Compilation time in milliseconds
  "filteredModules": 0, // A count of excluded modules when `exclude` is passed to the `toJson` method
  "assetsByChunkName": {
    // Chunk name to emitted asset(s) mapping
    "main": "web.js?h=11593e3b3ac85436984a",
    "named-chunk": "named-chunk.web.js",
    "other-chunk": [
      "other-chunk.js",
      "other-chunk.css"
    ]
  },
  "assets": [
    // A list of asset objects
  ],
  "chunks": [
    // A list of chunk objects
  ],
  "modules": [
    // A list of module objects
  ],
  "errors": [
    // A list of error strings
  ],
  "warnings": [
    // A list of warning strings
  ]
}
複製代碼

• modules：表示module的集合
  • module：webpack依賴樹中的真實模塊
• chunks：表示chunk的集合
  • chunk：包含entry入口、異步加載模塊、代碼分割（code spliting）後的代碼塊

經過對modules和chunks加以分析，就能夠獲得webpack完整的依賴關係，從而梳理出廢棄文件及廢棄代碼，同時也能夠根據業務形態進行定製。

3.4 webpack-deadcode-plugin

前面提到分析stats.json，但由於是原始數據，數據量比較大，有必定處理和清洗成本，因此可使用開源的webpack-deadcode-plugin這個插件

經過webpack-deadcode-plugin，能夠快速篩選出：

1. 未使用的文件
2. 未使用的已暴露變量

3.5 結合eslint、tslint進行治理

lint能夠快速的掃描出未使用的變量，這可以極大的提高咱們的deadcode清理效率。

1. 首先經過lint對未使用變量進行清理
2. 再經過webpack-deadcode-plugin再掃描出未使用文件和未使用的導出變量

頓時整個應用乾乾淨淨，舒舒服服！

---

參考

1. speed-measure-webpack-plugin

2. happyPack

3. webpack-bundle-analyzeer

4. stats

5. webpack-deadcode-plugin