一個webpack構建速度優化誤區

問題描述

項目中使用了一個npm包a。前幾天一直用得好好的，忽然某次拉了別的分支代碼後，就出Bug了。

第一反應是別人把這個包的版本變了。查看了下項目的package.json、package-lock.json文件，該模塊和依賴模塊的信息並無改變，node_modules/a中的版本信息也和package.json中的對應。

一會兒沒了頭緒，只好到node_modules中去調試一下。

TL;DR;

拉到最後看總結 XD

node_modules目錄結構

項目中node_modules目錄以下:

node_modules
│
└───a
│   │   index.js
|   |   ...
│   │
│   └───node_modules
│       │   ...
│       └───c
|           |   index.js
|           |   ...
│   
└───c
    │   index.js
    │   ...

從該目錄結構中能夠發現，模塊a的目錄下還有一個node_modules目錄，這個目錄裏放的是模塊a的依賴。眼尖的同窗可能發現了，項目自己的node_modules目錄和a模塊的node_modules目錄中都有安裝了模塊c。這是爲何呢？

緣由有2個:

1. 項目直接依賴了模塊c
2. 項目沒有直接依賴模塊c，可是項目直接依賴的模塊b中依賴了模塊c，而且和a中依賴的模塊c版本不兼容。

咱們的項目中並無直接引用模塊c，因此是第二種狀況。

npm的模塊安裝機制

本節主要解釋爲何項目沒有直接依賴模塊c，卻會把c安裝在項目的node_modules目錄下。不感興趣的同窗能夠直接跳過。

假設項目依賴了模塊a和模塊b，模塊a依賴模塊c的1.0.0版本，模塊b依賴模塊c的2.0.0版本。

npm2

在npm2的時候，使用嵌套的方式來安裝模塊，c模塊分別被安裝到a和b模塊的node_modules目錄中。

這種方式雖然簡單，可是卻會致使node_modules中存在大量相同的模塊。想象一下，若是模塊a和模塊依賴的模塊c都是1.0.0版本，使用這種方式就會產生冗餘的模塊。

npm3

到npm3的時候，npm2中產生冗餘模塊的狀況獲得改善。npm安裝模塊時會盡可能把模塊安裝到最外層的node_modules目錄中，讓模塊可以儘可能被複用。

1. 安裝模塊時，若是外層node_modules目錄中沒有同名模塊，就將其安裝到最外層ndoe_modules目錄中
2. 若是外層node_modules目錄中已經存在了同名模塊，而且版本兼容，則再也不安裝（使用時直接使用外層模塊）
3. 若是外層node_modules目錄中已經存在了同名模塊，而且版本不兼容，則安裝在父模塊的node_modules目錄中

上述狀況的安裝模塊如圖

引用了錯誤的模塊

到node_modules/a/node_modules/c/index.js中加了一些log，發現竟然沒執行！？

到這一步，要麼是log的位置沒寫對，要麼是沒有引入這個模塊。確認了webpack配置中的resolve.mainFields屬性和模塊c的package.json文件信息後，排除了第一種可能。

Tips: resolve.mainFields屬性用來告訴webpack，引入一個npm模塊時，如何找到這個模塊的入口。

這時候已經有點懵了，引用模塊時不是先從當前目錄下的node_modules目錄中開始一級一級向上查到嗎？說到向上查找，那便到上一級的node_modules目錄中去試一試。

果真！引用的是最外層node_modules中的模塊c！

難道webpack查找模塊的方式和Node.js不同嗎？仍是由於webpack的某些配置致使的？

使用以下webpack配置來構建，發現並無存在上述問題。

const path = require('path')
module.exports = {
  entry: './src/index.js',
  output: {
    filename: 'main.js',
    path: path.resolve(__dirname, './dist/js')
  },
};

那接下來只要排查究竟是哪些webpack配置影響到模塊檢索。查看項目中的webpack配置，和模塊檢索相關的只有resolve屬性。

const config = {
  resolve: {
    modules: [
        path.resolve(projectDir, 'src'),
        path.resolve(projectDir, 'node_modules'),
        path.resolve(imtPath, 'node_modules'),
    ],
    // es tree-shaking
    mainFields: ['jsnext:main', 'browser', 'main'],
    alias: {},
    extensions: ['.jsx', '.js'],
  }
}

所幸配置很少，對着webpack文檔查一下，很快便找到了問題：resolve.modules中使用了絕對路徑。如下爲webpack文檔原文：

告訴 webpack 解析模塊時應該搜索的目錄。

絕對路徑和相對路徑都能使用，可是要知道它們之間有一點差別。

經過查看當前目錄以及祖先路徑（即 ./node_modules, ../node_modules 等等），相對路徑將相似於 Node 查找 'node_modules' 的方式進行查找。

使用絕對路徑，將只在給定目錄中搜索。

上述webpack配置中，path.resolve(projectDir, 'node_modules')爲項目的node_modules目錄。這樣配置的緣由，是由於想要優化模塊檢索的速度，結果卻致使了這麼嚴重的Bug。

根據webpack文檔，就是由於這個絕對路徑致使了Bug。那麼只要把這個絕對路徑換成node_modules，Bug便解決了。

總結

npm在安裝模塊時，會優先將包安裝在node_modules目錄的最外層，除非有衝突纔會安裝到父模塊下的node_modules中。而webpack配置中的resolve.modules設置成項目node_modules目錄的絕對路徑時，會致使webpack在查找node_modules目錄時，只在最外層目錄查找，忽略掉更深層次的同名模塊。這與默認的查找策略「優先使用深層模塊」相反，致使構建時使用了錯誤的npm包。