[[226536]]

進入公司之后，接手的便是前人留下來的一個大項目。慶幸的是整個項目擁有完善的產品功能文檔，但是由于項目過于龐大，老舊。包含了打包過慢，冗余文件過多等諸多問題。想要快速的解決這些問題，想要完全把功能重構一遍的話，成本太高了。一個一個文件來過，時間成本也比較大。因此在此篇文章中，我們介紹一下我是如何配合webpack一步步進行分析，將項目進行優化的。

同時我針對思路封裝了一個webpack-unused-files，用于查找項目中的冗余文件，歡迎試用并star。

問題

首先，我們先大致看下我們都有什么問題，然后一步步進行解決

• 項目頻繁進行修改，冗余文件過多
• 部分第三方依賴濫用，想去除但是不知道在哪個文件中。或沒用，但是遺留在package.json里，
• 項目龐大，打包的結果過大，時間過長

刪除冗余文件

由于項目的頻繁改動，有很多文件已經不被使用并且沒有被刪除。由于項目的不斷擴大，只會影響我們定位功能和問題的速度，因此對冗余文件進行清理，是很重要的。但是我們單憑肉眼很難識別哪個文件是否被依賴的，因此還要通過webpack來解決。

1.獲取項目依賴的所有文件

我們來看一下webpack的輸出文件格式: 

{  
  ...  
  chunks: [{  
    name: 'chunk-name',  
    modules: [  
      // 每個chunk中所有的依賴文件  
    ]  
  }]  
  ...  
} 

所以說，根據這個stats.json，我們可以拿到在整個項目中拿到的所有項目文件: 

/**  
 * 查詢依賴的模塊  
 */  
function findSrcModules () {  
  return new Promise((resolve, reject) => {  
    fs.readFile(statPath, (err, data) => {  
      if (err) return  
      const json = JSON.parse(data)  
      const assetsList = json.chunks  
      let ret = []  
      // 拿到所有chunk的所有依賴文件  
      assetsList.forEach(chunk => {  
        const modules = chunk.modules.map(item => item.name)  
        ret = ret.concat(modules)  
      })  
      // 去除node_modules中的文件  
      ret = ret.filter(item => item.indexOf('node_modules') < 0)  
      resolve(ret)  
    })  
  })  
} 

通過這一步，我們可以拿到項目中，所有打包依賴的文件。

2.獲取項目中所有的文件

通過glob,我們可以獲取所有的文件: 

function getAllFilesInSrc () {  
  const pattern = './src/**'  
  return new Promise((resolve, reject) => {  
    glob(pattern, {  
      nodir: true  
    }, (err, files) => {  
      const ret = files.map(item => {  
        return item.replace('./src', '.')  
      })  
      resolve(ret)  
    })  
  })  
} 

3.將兩個文件數組進行對比，然后進行刪除等操作：

將兩個數組進行對比，沒有出現在依賴中的文件，就是冗余文件。我們可以一鍵刪除 

findSrcModules().then(ret => {  
  getAllFilesInSrc().then(allFiles => {  
    const unUsed = allFiles.filter(item => {  
      return ret.indexOf(item) < 0  
    })  
    const join = p => path.join('./src', p)  
 
    unUsed.forEach(file => {  
      shelljs.rm(join(file))  
    })  
  })  
}) 

分析第三方依賴

根據上述冗余文件的思路，我們同樣可以對第三方依賴進行處理，大致思路如下

• 獲取所有包含node_modules的依賴
• 將文件名進行截取、去重。獲取到所有的依賴
• 與package.json進行對比，拿到沒有使用的依賴
• 將對比結果進行分析，將不想使用的依賴保存下來
• 再次查找stat.json，查找該依賴的reson字段，獲取再哪里引用了該依賴，進行輸出
• 將依賴進行手動替換、刪除等操作

可以說，拿到了所有依賴及依賴關系，我們可以很靈活的對其進行處理，拿到我們想要的結果。

該功能后續也會更新到webpack-unused-files中去。

優化打包大小

讓人震驚的是，整個項目由于種種原因，打包后的大小有近20M的大小！雖然并不是TO C項目，并且針對頁面進行了代碼拆分和懶加載，但是作為一個“合格的前端”，這種現象是一定要修改的（沒錯！）。該如何下手呢？一個個的翻代碼，看看我們都引用了什么大依賴，看哪些項目過大未免太復雜了。我們看看webpack給我嗎提供了什么方案：

1.展示打包結果

我們知道，在webpack打包結束后，會自動在控制臺顯示打包結果。同時，他也提供了輸出依賴及大小的功能，我們執行以下參數, 便可將所有的依賴進行展示，并且看到他們的大小了。

webpack --display-modules --sort-modules-by size 

結果類似這樣： 

我們可以很快的定位到排名前幾的js文件或者第三方依賴，決定該如何對其進行處置。

2.可視化分析依賴

webpack提供了一個功能，將打包的所有依賴文件以及關系，以json格式進行輸出： 

webpack --profile --json > stats.json 

這是我們整篇文章的一個基礎，很多人基于此封裝了不少可視化分析的工具,可以直觀的看到各個

文件、chunk之間的依賴關系以及大小等，快速定位到大文件、大模塊

webpack analyse 

webpack chart 

3.優化方案

通過以上兩種方法，我們可以很好的對內容文件和依賴進行定位和分析，針對打包大小的優化方案網上已經有很多了，在此不再進行贅述，提供幾個思路及參考：

• CommonsChunkPlugin提取公共代碼
• dll-plugin進行大文件單獨打包，緩存
• 刪除無用的依賴（后面會提到
• 選擇性的棄用一些依賴
• 代碼壓縮
• babel-polyfill
• Scope Hoisting

優化打包時間

針對打包時間的優化的文章其實也很多了，我們在此僅提供一些思路。我們主要提一點，通過構建會發現，項目中引用了大量的svg圖標以及國旗圖標，每次在靜態資源處理中，打包時間就會變的特別慢。

我們在項目中使用的svg-sprite-loader，自動將各個svg圖標進行svg-spirte。但是我們知道，這些圖標一旦引用，我們很少進行修改。尤其是像國旗圖標這種，但是每次構建我們都需要進行重復打包。因此，我們可以提前把這些圖標進行svg-sprite。推薦一個網站，將各種svg圖標提前進行sprite并自動進行引用：

iconmoon

日常打包時間優化點

• externals 避免打包大的第三方依賴
• dll-plugin 預打包第三方依賴
• happypack 多進程處理，緩存
• 緩存與增量構建
  • babel-loader?cacheDirectory
  • webpack cache:true
• 減少構建搜索或編譯路徑 alias resolve
• 具象打包的范圍 include exclude

總結

通過對webpack輸出依賴關系的json的分析，我們可以直觀的拿到以下數據：

• 所有依賴文件及其大小
• 每個依賴文件是被哪些文件引用的
• 項目依賴的第三方依賴

通過這些數據，我們可以很方便的對現有項目進行優化。

生命不息，倒騰不止。讓我們對所有的惡心代碼說再見！  

原文鏈接：http://callmedadaxin.github.io/2018/04/13/analyse-project-with-webpack/