問題描述

項(xiàng)目中使用了一個(gè)npm包a。前幾天一直用得好好的，突然某次拉了別的分支代碼后，就出Bug了。

第一反應(yīng)是別人把這個(gè)包的版本變了。查看了下項(xiàng)目的package.json、package-lock.json文件，該模塊和依賴模塊的信息并沒有改變，node_modules/a中的版本信息也和package.json中的對(duì)應(yīng)。

一下子沒了頭緒，只好到node_modules中去調(diào)試一下。

TL;DR;

拉到最后看總結(jié) XD

node_modules目錄結(jié)構(gòu)

項(xiàng)目中node_modules目錄如下:

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

從該目錄結(jié)構(gòu)中可以發(fā)現(xiàn)，模塊a的目錄下還有一個(gè)node_modules目錄，這個(gè)目錄里放的是模塊a的依賴。眼尖的同學(xué)可能發(fā)現(xiàn)了，項(xiàng)目本身的node_modules目錄和a模塊的node_modules目錄中都有安裝了模塊c。這是為什么呢？

原因有2個(gè):

1. 項(xiàng)目直接依賴了模塊c
2. 項(xiàng)目沒有直接依賴模塊c，但是項(xiàng)目直接依賴的模塊b中依賴了模塊c，并且和a中依賴的模塊c版本不兼容。

我們的項(xiàng)目中并沒有直接引用模塊c，所以是第二種情況。

npm的模塊安裝機(jī)制

本節(jié)主要解釋為什么項(xiàng)目沒有直接依賴模塊c，卻會(huì)把c安裝在項(xiàng)目的node_modules目錄下。不感興趣的同學(xué)可以直接跳過。

假設(shè)項(xiàng)目依賴了模塊a和模塊b，模塊a依賴模塊c的1.0.0版本，模塊b依賴模塊c的2.0.0版本。

npm2

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

這種方式雖然簡(jiǎn)單，但是卻會(huì)導(dǎo)致node_modules中存在大量相同的模塊。想象一下，如果模塊a和模塊依賴的模塊c都是1.0.0版本，使用這種方式就會(huì)產(chǎn)生冗余的模塊。

npm3

到npm3的時(shí)候，npm2中產(chǎn)生冗余模塊的情況得到改善。npm安裝模塊時(shí)會(huì)盡量把模塊安裝到最外層的node_modules目錄中，讓模塊能夠盡量被復(fù)用。

1. 安裝模塊時(shí)，如果外層node_modules目錄中沒有同名模塊，就將其安裝到最外層ndoe_modules目錄中
2. 如果外層node_modules目錄中已經(jīng)存在了同名模塊，并且版本兼容，則不再安裝（使用時(shí)直接使用外層模塊）
3. 如果外層node_modules目錄中已經(jīng)存在了同名模塊，并且版本不兼容，則安裝在父模塊的node_modules目錄中

上述情況的安裝模塊如圖

引用了錯(cuò)誤的模塊

到node_modules/a/node_modules/c/index.js中加了一些log，發(fā)現(xiàn)居然沒執(zhí)行??？

到這一步，要么是log的位置沒寫對(duì)，要么是沒有引入這個(gè)模塊。確認(rèn)了webpack配置中的resolve.mainFields屬性和模塊c的package.json文件信息后，排除了第一種可能。

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

這時(shí)候已經(jīng)有點(diǎn)懵了，引用模塊時(shí)不是先從當(dāng)前目錄下的node_modules目錄中開始一級(jí)一級(jí)向上查到嗎？說到向上查找，那便到上一級(jí)的node_modules目錄中去試一試。

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

難道webpack查找模塊的方式和Node.js不一樣嗎？還是因?yàn)閣ebpack的某些配置導(dǎo)致的？

使用如下webpack配置來構(gòu)建，發(fā)現(xiàn)并沒有存在上述問題。

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

那接下來只要排查到底是哪些webpack配置影響到模塊檢索。查看項(xiàng)目中的webpack配置，和模塊檢索相關(guān)的只有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'],
 }
}

所幸配置不多，對(duì)著webpack文檔查一下，很快便找到了問題：resolve.modules中使用了絕對(duì)路徑。以下為webpack文檔原文：

告訴 webpack 解析模塊時(shí)應(yīng)該搜索的目錄。

絕對(duì)路徑和相對(duì)路徑都能使用，但是要知道它們之間有一點(diǎn)差異。

通過查看當(dāng)前目錄以及祖先路徑（即 ./node_modules, ../node_modules 等等），相對(duì)路徑將類似于 Node 查找 'node_modules' 的方式進(jìn)行查找。

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

上述webpack配置中，path.resolve(projectDir, 'node_modules')為項(xiàng)目的node_modules目錄。這樣配置的原因，是因?yàn)橄胍獌?yōu)化模塊檢索的速度，結(jié)果卻導(dǎo)致了這么嚴(yán)重的Bug。

根據(jù)webpack文檔，就是因?yàn)檫@個(gè)絕對(duì)路徑導(dǎo)致了Bug。那么只要把這個(gè)絕對(duì)路徑換成node_modules，Bug便解決了。

總結(jié)

npm在安裝模塊時(shí)，會(huì)優(yōu)先將包安裝在node_modules目錄的最外層，除非有沖突才會(huì)安裝到父模塊下的node_modules中。而webpack配置中的resolve.modules設(shè)置成項(xiàng)目node_modules目錄的絕對(duì)路徑時(shí)，會(huì)導(dǎo)致webpack在查找node_modules目錄時(shí)，只在最外層目錄查找，忽略掉更深層次的同名模塊。這與默認(rèn)的查找策略“優(yōu)先使用深層模塊”相反，導(dǎo)致構(gòu)建時(shí)使用了錯(cuò)誤的npm包。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。