前端工程化 - 剖析npm的包管理機制

導讀

現如今，前端開發的同學已經離不開 npm 這個包管理工具，其優秀的包版本管理機制承載了整個繁榮發展的NodeJS社區，理解其內部機制非常有利於加深我們對模塊開發的理解、各項前端工程化的配置以加快我們排查問題（相信不少同學收到過各種依賴問題的困擾）的速度。

本文從三個角度：package.json、版本管理、依賴安裝結合具體實例對 npm 的包管理機制進行了詳細分析。

一、剖析 package.json

在 Node.js 中，模塊是一個庫或框架，也是一個 Node.js 項目。Node.js 項目遵循模塊化的架構，當我們創建了一個 Node.js 項目，意味着創建了一個模塊，這個模塊必須有一個描述文件，即 package.json。它是我們最常見的配置文件，但是它裏面的配置你真的有詳細瞭解過嗎？配置一個合理的 package.json 文件直接決定着我們項目的質量，所以首先帶大家分析下 package.json 的各項詳細配置。

1.1 必備屬性

package.json 中有非常多的屬性，其中必須填寫的只有兩個：name 和 version ，這兩個屬性組成一個 npm 模塊的唯一標識。

npm包命名規則

name 即模塊名稱，其命名時需要遵循官方的一些規範和建議：

• 包名會成爲模塊url、命令行中的一個參數或者一個文件夾名稱，任何非url安全的字符在包名中都不能使用，可以使用 validate-npm-package-name 包來檢測包名是否合法。

• 語義化包名，可以幫助開發者更快的找到需要的包，並且避免意外獲取錯誤的包。

• 若包名稱中存在一些符號，將符號去除後不得與現有包名重複

例如：由於react-native已經存在，react.native、reactnative都不可以再創建。

• 如果你的包名與現有的包名太相近導致你不能發佈這個包，那麼推薦將這個包發佈到你的作用域下。

例如：用戶名 conard，那麼作用域爲 @conard，發佈的包可以是@conard/react。

查看包是否被佔用

name 是一個包的唯一標識，不得和其他包名重複，我們可以執行 npm view packageName 查看包是否被佔用，並可以查看它的一些基本信息：

若包名稱從未被使用過，則會拋出 404 錯誤：

另外，你還可以去 https://www.npmjs.com/ 查詢更多更詳細的包信息。

1.2描述信息

基本描述

{
  "description": "An enterprise-class UI design language and React components implementation",
  "keywords": [
    "ant",
    "component",
    "components",
    "design",
    "framework",
    "frontend",
    "react",
    "react-component",
    "ui"
  ]
}

description用於添加模塊的的描述信息，方便別人瞭解你的模塊。

keywords用於給你的模塊添加關鍵字。

當然，他們的還有一個非常重要的作用，就是利於模塊檢索。當你使用 npm search 檢索模塊時，會到description 和 keywords 中進行匹配。寫好 description 和 keywords 有利於你的模塊獲得更多更精準的曝光：

開發人員

描述開發人員的字段有兩個：author 和 contributors， author 指包的主要作者，一個 author 對應一個人。 contributors 指貢獻者信息，一個 contributors 對應多個貢獻者，值爲數組，對人的描述可以是一個字符串，也可以是下面的結構：

{ 
    "name" : "ConardLi", 
    "email" : "[email protected]", 
    "url" : "https://github.com/ConardLi"
}

地址

{
  "homepage": "http://ant.design/",
  "bugs": {
    "url": "https://github.com/ant-design/ant-design/issues"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/ant-design/ant-design"
  },
}

homepage 用於指定該模塊的主頁。

repository 用於指定模塊的代碼倉庫。

bugs 指定一個地址或者一個郵箱，對你的模塊存在疑問的人可以到這裏提出問題。

1.3 依賴配置

我們的項目可能依賴一個或多個外部依賴包，根據依賴包的不同用途，我們將他們配置在下面幾個屬性下：dependencies、devDependencies、peerDependencies、bundledDependencies、optionalDependencies。

配置規則

在介紹幾種依賴配置之前，首先我們來看一下依賴的配置規則，你看到的依賴包配置可能是下面這樣的：

 "dependencies": {
      "antd": "ant-design/ant-design#4.0.0-alpha.8",
      "axios": "^1.2.0",
      "test-js": "file:../test",
      "test2-js": "http://cdn.com/test2-js.tar.gz",
      "core-js": "^1.1.5",
 }

依賴配置遵循下面幾種配置規則：

• 依賴包名稱:VERSION
  • VERSION是一個遵循SemVer規範的版本號配置，npm install 時將到npm服務器下載符合指定版本範圍的包。
• 依賴包名稱:DWONLOAD_URL
  • DWONLOAD_URL 是一個可下載的tarball壓縮包地址，模塊安裝時會將這個.tar下載並安裝到本地。
• 依賴包名稱:LOCAL_PATH
  • LOCAL_PATH 是一個本地的依賴包路徑，例如 file:../pacakges/pkgName。適用於你在本地測試一個npm包，不應該將這種方法應用於線上。
• 依賴包名稱:GITHUB_URL
  • GITHUB_URL 即 github 的 username/modulename 的寫法，例如：ant-design/ant-design，你還可以在後面指定 tag 和 commit id。
• 依賴包名稱:GIT_URL
  • GIT_URL 即我們平時clone代碼庫的 git url，其遵循以下形式：

<protocol>://[<user>[:<password>]@]<hostname>[:<port>][:][/]<path>[#<commit-ish> | #semver:<semver>]

其中 protocal 可以是以下幾種形式：

• git://github.com/user/project.git#commit-ish
• git+ssh://user@hostname:project.git#commit-ish
• git+ssh://user@hostname/project.git#commit-ish
• git+http://user@hostname/project/blah.git#commit-ish
• git+https://user@hostname/project/blah.git#commit-ish

dependencies

dependencies 指定了項目運行所依賴的模塊，開發環境和生產環境的依賴模塊都可以配置到這裏，例如

 "dependencies": {
      "lodash": "^4.17.13",
      "moment": "^2.24.0",
 }

devDependencies

有一些包有可能你只是在開發環境中用到，例如你用於檢測代碼規範的 eslint ,用於進行測試的 jest ，用戶使用你的包時即使不安裝這些依賴也可以正常運行，反而安裝他們會耗費更多的時間和資源，所以你可以把這些依賴添加到 devDependencies 中，這些依賴照樣會在你本地進行 npm install 時被安裝和管理，但是不會被安裝到生產環境：

 "devDependencies": {
      "jest": "^24.3.1",
      "eslint": "^6.1.0",
 }

peerDependencies

peerDependencies 用於指定你正在開發的模塊所依賴的版本以及用戶安裝的依賴包版本的兼容性。

上面的說法可能有點太抽象，我們直接拿 ant-design 來舉個例子，ant-design 的 package.json 中有如下配置：

  "peerDependencies": {
    "react": ">=16.0.0",
    "react-dom": ">=16.0.0"
  }

當你正在開發一個系統，使用了 ant-design ，所以也肯定需要依賴 React。同時， ant-design 也是需要依賴 React 的，它要保持穩定運行所需要的 React 版本是16.0.0，而你開發時依賴的 React 版本是 15.x：

這時，ant-design 要使用 React，並將其引入：

import * as React from 'react';
import * as ReactDOM from 'react-dom';

這時取到的是宿主環境也就是你的環境中的 React 版本，這就可能造成一些問題。在 npm2 的時候，指定上面的 peerDependencies 將意味着強制宿主環境安裝 react@>=16.0.0和react-dom@>=16.0.0 的版本。

npm3 以後不會再要求 peerDependencies 所指定的依賴包被強制安裝，相反 npm3 會在安裝結束後檢查本次安裝是否正確，如果不正確會給用戶打印警告提示。

  "dependencies": {
    "react": "15.6.0",
    "antd": "^3.22.0"
  }

例如，我在項目中依賴了 antd 的最新版本，然後依賴了 react 的 15.6.0版本，在進行依賴安裝時將給出以下警告：

optionalDependencies

某些場景下，依賴包可能不是強依賴的，這個依賴包的功能可有可無，當這個依賴包無法被獲取到時，你希望 npm install 繼續運行，而不會導致失敗，你可以將這個依賴放到 optionalDependencies 中，注意 optionalDependencies 中的配置將會覆蓋掉 dependencies 所以只需在一個地方進行配置。

當然，引用 optionalDependencies 中安裝的依賴時，一定要做好異常處理，否則在模塊獲取不到時會導致報錯。

bundledDependencies

和以上幾個不同，bundledDependencies 的值是一個數組，數組裏可以指定一些模塊，這些模塊將在這個包發佈時被一起打包。

  "bundledDependencies": ["package1" , "package2"]

1.4 協議

{
    "license": "MIT"
}

license 字段用於指定軟件的開源協議，開源協議裏面詳盡表述了其他人獲得你代碼後擁有的權利，可以對你的的代碼進行何種操作，何種操作又是被禁止的。同一款協議有很多變種，協議太寬鬆會導致作者喪失對作品的很多權利，太嚴格又不便於使用者使用及作品的傳播，所以開源作者要考慮自己對作品想保留哪些權利，放開哪些限制。

軟件協議可分爲開源和商業兩類，對於商業協議，或者叫法律聲明、許可協議，每個軟件會有自己的一套行文，由軟件作者或專門律師撰寫，對於大多數人來說不必自己花時間和精力去寫繁長的許可協議，選擇一份廣爲流傳的開源協議就是個不錯的選擇。

以下就是幾種主流的開源協議：

• MIT：只要用戶在項目副本中包含了版權聲明和許可聲明，他們就可以拿你的代碼做任何想做的事情，你也無需承擔任何責任。
• Apache：類似於 MIT，同時還包含了貢獻者向用戶提供專利授權相關的條款。
• GPL：修改項目代碼的用戶再次分發源碼或二進制代碼時，必須公佈他的相關修改。

如果你對開源協議有更詳細的要求，可以到 https://choosealicense.com/ 獲取更詳細的開源協議說明。

1.5 目錄、文件相關

程序入口

{
  "main": "lib/index.js",
}

main 屬性可以指定程序的主入口文件，例如，上面 antd 指定的模塊入口 lib/index.js ，當我們在代碼用引入 antd 時：import { notification } from 'antd'; 實際上引入的就是 lib/index.js 中暴露出去的模塊。

命令行工具入口

當你的模塊是一個命令行工具時，你需要爲命令行工具指定一個入口，即指定你的命令名稱和本地可指定文件的對應關係。如果是全局安裝，npm 將會使用符號鏈接把可執行文件鏈接到 /usr/local/bin，如果是本地安裝，會鏈接到 ./node_modules/.bin/。

{
    "bin": {
    "conard": "./bin/index.js"
  }
}

例如上面的配置：當你的包安裝到全局時：npm 會在 /usr/local/bin下創建一個以 conard 爲名字的軟鏈接，指向全局安裝下來的 conard 包下面的 "./bin/index.js"。這時你在命令行執行 conard 則會調用鏈接到的這個js文件。

這裏不再過多展開，更多內容在我後續的命令行工具文章中會進行詳細講解。

發佈文件配置

{
    "files": [
      "dist",
      "lib",
      "es"
    ]
}

files 屬性用於描述你 npm publish 後推送到 npm 服務器的文件列表，如果指定文件夾，則文件夾內的所有內容都會包含進來。我們可以看到下載後的包是下面的目錄結構：

另外，你還可以通過配置一個 .npmignore 文件來排除一些文件, 防止大量的垃圾文件推送到 npm, 規則上和你用的 .gitignore 是一樣的。.gitignore 文件也可以充當.npmignore 文件。

man

man 命令是 Linux 下的幫助指令，通過 man 指令可以查看 Linux 中的指令幫助、配置文件幫助和編程幫助等信息。

如果你的 node.js 模塊是一個全局的命令行工具，在 package.json 通過 man 屬性可以指定 man 命令查找的文檔地址。

man 文件必須以數字結尾，或者如果被壓縮了，以 .gz 結尾。數字表示文件將被安裝到 man 的哪個部分。如果 man 文件名稱不是以模塊名稱開頭的，安裝的時候會給加上模塊名稱前綴。

例如下面這段配置：

{ 
  "man" : [ 
    "/Users/isaacs/dev/npm/cli/man/man1/npm-access.1",
    "/Users/isaacs/dev/npm/cli/man/man1/npm-audit.1"
  ]
}

在命令行輸入 man npm-audit ：

規範項目目錄

一個 node.js 模塊是基於 CommonJS 模塊化規範實現的，嚴格按照 CommonJS 規範，模塊目錄下除了必須包含包描述文件 package.json 以外，還需要包含以下目錄：

• bin：存放可執行二進制文件的目錄
• lib：存放js代碼的目錄
• doc：存放文檔的目錄
• test：存放單元測試用例代碼的目錄
• …

在模塊目錄中你可能沒有嚴格按照以上結構組織或命名，你可以通過在 package.json 指定 directories 屬性來指定你的目錄結構和上述的規範結構的對應情況。除此之外 directories 屬性暫時沒有其他應用。

{
  "directories": {
    "lib": "src/lib/",
    "bin": "src/bin/",
    "man": "src/man/",
    "doc": "src/doc/",
    "example": "src/example/"
  }
}

不過官方文檔表示，雖然目前這個屬性沒有什麼重要作用，未來可能會整出一些花樣出來，例如：doc 中存放的 markdown 文件、example 中存放的示例文件，可能會友好的展示出來。

1.6 腳本配置

script

{
  "scripts": {
    "test": "jest --config .jest.js --no-cache",
    "dist": "antd-tools run dist",
    "compile": "antd-tools run compile",
    "build": "npm run compile && npm run dist"
  }
}

scripts 用於配置一些腳本命令的縮寫，各個腳本可以互相組合使用，這些腳本可以覆蓋整個項目的生命週期，配置後可使用 npm run command 進行調用。如果是 npm 關鍵字，則可以直接調用。例如，上面的配置制定了以下幾個命令：npm run test、npm run dist、npm run compile、npm run build。

config

config 字段用於配置腳本中使用的環境變量，例如下面的配置，可以在腳本中使用process.env.npm_package_config_port進行獲取。

{
  "config" : { "port" : "8080" }
}

1.7 發佈配置

preferGlobal

如果你的 node.js 模塊主要用於安裝到全局的命令行工具，那麼該值設置爲 true ，當用戶將該模塊安裝到本地時，將得到一個警告。這個配置並不會阻止用戶安裝，而是會提示用戶防止錯誤使用而引發一些問題。

private

如果將 private 屬性設置爲 true，npm將拒絕發佈它，這是爲了防止一個私有模塊被無意間發佈出去。

publishConfig

  "publishConfig": {
    "registry": "https://registry.npmjs.org/"
  },

發佈模塊時更詳細的配置，例如你可以配置只發布某個 tag、配置發佈到的私有 npm 源。更詳細的配置可以參考 npm-config

os

假如你開發了一個模塊，只能跑在 darwin 系統下，你需要保證 windows 用戶不會安裝到你的模塊，從而避免發生不必要的錯誤。

使用 os 屬性可以幫助你完成以上的需求，你可以指定你的模塊只能被安裝在某些系統下，或者指定一個不能安裝的系統黑名單：

"os" : [ "darwin", "linux" ]
"os" : [ "!win32" ]

例如，我把一個測試模塊指定一個系統黑名單："os" : [ "!darwin" ]，當我在此係統下安裝它時會爆出如下錯誤：

在node環境下可以使用 process.platform 來判斷操作系統。

cpu

和上面的 os 類似，我們可以用 cpu 屬性更精準的限制用戶安裝環境：

"cpu" : [ "x64", "ia32" ]
"cpu" : [ "!arm", "!mips" ]

在node環境下可以使用 process.arch 來判斷 cpu 架構。

二、剖析包版本管理機制

Nodejs成功離不開 npm 優秀的依賴管理系統。在介紹整個依賴系統之前，必須要瞭解 npm如何管理依賴包的版本，本章將介紹 npm包 的版本發佈規範、如何管理各種依賴包的版本以及一些關於包版本的最佳實踐。

2.1 查看npm包版本

你可以執行 npm view package version 查看某個 package 的最新版本。

執行 npm view conard versions 查看某個 package 在npm服務器上所有發佈過的版本。

執行 npm ls 可查看當前倉庫依賴樹上所有包的版本信息。

2.2 SemVer規範

npm包 中的模塊版本都需要遵循 SemVer規範——由 Github 起草的一個具有指導意義的，統一的版本號表示規則。實際上就是 Semantic Version（語義化版本）的縮寫。

SemVer規範官網： https://semver.org/

標準版本

SemVer規範的標準版本號採用 X.Y.Z 的格式，其中 X、Y 和 Z 爲非負的整數，且禁止在數字前方補零。X 是主版本號、Y 是次版本號、而 Z 爲修訂號。每個元素必須以數值來遞增。

• 主版本號(major)：當你做了不兼容的API 修改
• 次版本號(minor)：當你做了向下兼容的功能性新增
• 修訂號(patch)：當你做了向下兼容的問題修正。

例如：1.9.1 -> 1.10.0 -> 1.11.0

先行版本

當某個版本改動比較大、並非穩定而且可能無法滿足預期的兼容性需求時，你可能要先發佈一個先行版本。

先行版本號可以加到“主版本號.次版本號.修訂號”的後面，先加上一個連接號再加上一連串以句點分隔的標識符和版本編譯信息。

• 內部版本(alpha):
• 公測版本(beta):
• 正式版本的候選版本rc: 即 Release candiate

React的版本

下面我們來看看 React 的歷史版本：

可見是嚴格按照 SemVer 規範來發版的：

• 版本號嚴格按照 主版本號.次版本號.修訂號 格式命名
• 版本是嚴格遞增的，：16.8.0 -> 16.8.1 -> 16.8.2
• 發佈重大版本或版本改動較大時，先發布alpha、beta、rc等先行版本

發佈版本

在修改 npm 包某些功能後通常需要發佈一個新的版本，我們通常的做法是直接去修改 package.json 到指定版本。如果操作失誤，很容易造成版本號混亂，我們可以藉助符合 Semver 規範的命令來完成這一操作：

• npm version patch : 升級修訂版本號
• npm version minor : 升級次版本號
• npm version major : 升級主版本號

2.3 版本工具使用

在開發中肯定少不了對一些版本號的操作，如果這些版本號符合 SemVer規範 ，我們可以藉助用於操作版本的npm包semver來幫助我們進行比較版本大小、提取版本信息等操作。

Npm 也使用了該工具來處理版本相關的工作。

npm install semver

• 比較版本號大小

semver.gt('1.2.3', '9.8.7') // false
semver.lt('1.2.3', '9.8.7') // true

• 判斷版本號是否符合規範，返回解析後符合規範的版本號。

semver.valid('1.2.3') // '1.2.3'
semver.valid('a.b.c') // null

• 將其他版本號強制轉換成semver版本號

semver.valid(semver.coerce('v2')) // '2.0.0'
semver.valid(semver.coerce('42.6.7.9.3-alpha')) // '42.6.7'

• 一些其他用法

semver.clean('  =v1.2.3   ') // '1.2.3'
semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
semver.minVersion('>=1.0.0') // '1.0.0'

以上都是semver最常見的用法，更多詳細內容可以查看 semver文檔：https://github.com/npm/node-semver

2.4 依賴版本管理

我們經常看到，在 package.json 中各種依賴的不同寫法：

  "dependencies": {
    "signale": "1.4.0",
    "figlet": "*",
    "react": "16.x",
    "table": "~5.4.6",
    "yargs": "^14.0.0"
  }

前面三個很容易理解：

• "signale": "1.4.0": 固定版本號
• "figlet": "*": 任意版本（>=0.0.0）
• "react": "16.x": 匹配主要版本（>=16.0.0 <17.0.0）
• "react": "16.3.x": 匹配主要版本和次要版本（>=16.3.0 <16.4.0）

再來看看後面兩個，版本號中引用了 ~ 和 ^ 符號：

• ~: 當安裝依賴時獲取到有新版本時，安裝到 x.y.z 中 z 的最新的版本。即保持主版本號、次版本號不變的情況下，保持修訂號的最新版本。
• ^: 當安裝依賴時獲取到有新版本時，安裝到 x.y.z 中 y 和 z 都爲最新版本。 即保持主版本號不變的情況下，保持次版本號、修訂版本號爲最新版本。

在 package.json 文件中最常見的應該是 "yargs": "^14.0.0" 這種格式的 依賴, 因爲我們在使用 npm install package 安裝包時，npm 默認安裝當前最新版本，然後在所安裝的版本號前加 ^ 號。

注意，當主版本號爲 0 的情況，會被認爲是一個不穩定版本，情況與上面不同：

• 主版本號和次版本號都爲 0: ^0.0.z、~0.0.z 都被當作固定版本，安裝依賴時均不會發生變化。
• 主版本號爲 0: ^0.y.z 表現和 ~0.y.z 相同，只保持修訂號爲最新版本。

1.0.0 的版本號用於界定公共 API。當你的軟件發佈到了正式環境，或者有穩定的API時，就可以發佈1.0.0版本了。所以，當你決定對外部發佈一個正式版本的npm包時，把它的版本標爲1.0.0。

2.5 鎖定依賴版本

lock文件

實際開發中，經常會因爲各種依賴不一致而產生奇怪的問題，或者在某些場景下，我們不希望依賴被更新，建議在開發中使用 package-lock.json。

鎖定依賴版本意味着在我們不手動執行更新的情況下，每次安裝依賴都會安裝固定版本。保證整個團隊使用版本號一致的依賴。

每次安裝固定版本，無需計算依賴版本範圍，大部分場景下能大大加速依賴安裝時間。

使用 package-lock.json 要確保npm的版本在5.6以上，因爲在5.0 - 5.6中間，對 package-lock.json的處理邏輯進行過幾次更新，5.6版本後處理邏輯逐漸穩定。

關於 package-lock.json 詳細的結構，我們會在後面的章節進行解析。

定期更新依賴

我們的目的是保證團隊中使用的依賴一致或者穩定，而不是永遠不去更新這些依賴。實際開發場景下，我們雖然不需要每次都去安裝新的版本，仍然需要定時去升級依賴版本，來讓我們享受依賴包升級帶來的問題修復、性能提升、新特性更新。

使用 npm outdated 可以幫助我們列出有哪些還沒有升級到最新版本的依賴：

• 黃色表示不符合我們指定的語意化版本範圍 - 不需要升級
• 紅色表示符合指定的語意化版本範圍 - 需要升級

執行 npm update 會升級所有的紅色依賴。

2.6 依賴版本選擇的最佳實踐

版本發佈

• 對外部發佈一個正式版本的npm包時，把它的版本標爲1.0.0。
• 某個包版本發行後，任何修改都必須以新版本發行。
• 版本號嚴格按照 主版本號.次版本號.修訂號 格式命名
• 版本號發佈必須是嚴格遞增的
• 發佈重大版本或版本改動較大時，先發布alpha、beta、rc等先行版本

依賴範圍選擇

• 主工程依賴了很多子模塊，都是團隊成員開發的npm包，此時建議把版本前綴改爲~，如果鎖定的話每次子依賴更新都要對主工程的依賴進行升級，非常繁瑣，如果對子依賴完全信任，直接開啓^每次升級到最新版本。
• 主工程跑在docker線上，本地還在進行子依賴開發和升級，在docker版本發佈前要鎖定所有依賴版本，確保本地子依賴發佈後線上不會出問題。

保持依賴一致

• 確保npm的版本在5.6以上，確保默認開啓 package-lock.json 文件。
• 由初始化成員執行 npm inatall 後，將 package-lock.json 提交到遠程倉庫。不要直接提交 node_modules到遠程倉庫。
• 定期執行 npm update 升級依賴，並提交 lock 文件確保其他成員同步更新依賴，不要手動更改 lock 文件。

依賴變更

• 升級依賴: 修改 package.json文件的依賴版本，執行 npm install
• 降級依賴: 直接執行 npm install package@version(改動package.json不會對依賴進行降級)
• 注意改動依賴後提交lock文件

三、剖析 npm install 原理

npm install 大概會經過上面的幾個流程，這一章就來講一講各個流程的實現細節、發展以及爲何要這樣實現。

3.1 嵌套結構

我們都知道，執行 npm install 後，依賴包被安裝到了 node_modules ，下面我們來具體瞭解下，npm 將依賴包安裝到 node_modules 的具體機制是什麼。

在 npm 的早期版本， npm 處理依賴的方式簡單粗暴，以遞歸的形式，嚴格按照 package.json 結構以及子依賴包的 package.json 結構將依賴安裝到他們各自的 node_modules 中。直到有子依賴包不在依賴其他模塊。

舉個例子，我們的模塊 my-app 現在依賴了兩個模塊：buffer、ignore：

{
  "name": "my-app",
  "dependencies": {
    "buffer": "^5.4.3",
    "ignore": "^5.1.4",
  }
}

ignore是一個純 JS 模塊，不依賴任何其他模塊，而 buffer 又依賴了下面兩個模塊：base64-js 、 ieee754。

{
  "name": "buffer",
  "dependencies": {
    "base64-js": "^1.0.2",
    "ieee754": "^1.1.4"
  }
}

那麼，執行 npm install 後，得到的 node_modules 中模塊目錄結構就是下面這樣的：

這樣的方式優點很明顯， node_modules 的結構和 package.json 結構一一對應，層級結構明顯，並且保證了每次安裝目錄結構都是相同的。

但是，試想一下，如果你依賴的模塊非常之多，你的 node_modules 將非常龐大，嵌套層級非常之深：

• 在不同層級的依賴中，可能引用了同一個模塊，導致大量冗餘。
• 在 Windows 系統中，文件路徑最大長度爲260個字符，嵌套層級過深可能導致不可預知的問題。

3.2 扁平結構

爲了解決以上問題，NPM 在 3.x 版本做了一次較大更新。其將早期的嵌套結構改爲扁平結構：

• 安裝模塊時，不管其是直接依賴還是子依賴的依賴，優先將其安裝在 node_modules 根目錄。

還是上面的依賴結構，我們在執行 npm install 後將得到下面的目錄結構：

此時我們若在模塊中又依賴了 [email protected] 版本：

{
  "name": "my-app",
  "dependencies": {
    "buffer": "^5.4.3",
    "ignore": "^5.1.4",
    "base64-js": "1.0.1",
  }
}

• 當安裝到相同模塊時，判斷已安裝的模塊版本是否符合新模塊的版本範圍，如果符合則跳過，不符合則在當前模塊的 node_modules 下安裝該模塊。

此時，我們在執行 npm install 後將得到下面的目錄結構：

對應的，如果我們在項目代碼中引用了一個模塊，模塊查找流程如下：

• 在當前模塊路徑下搜索
• 在當前模塊 node_modules 路徑下搜素
• 在上級模塊的 node_modules 路徑下搜索
• …
• 直到搜索到全局路徑中的 node_modules

假設我們又依賴了一個包 buffer2@^5.4.3，而它依賴了包 [email protected]，則此時的安裝結構是下面這樣的：

所以 npm 3.x 版本並未完全解決老版本的模塊冗餘問題，甚至還會帶來新的問題。

試想一下，你的APP假設沒有依賴 [email protected] 版本，而你同時依賴了依賴不同 base64-js 版本的 buffer 和 buffer2。由於在執行 npm install 的時候，按照 package.json 裏依賴的順序依次解析，則 buffer 和 buffer2 在 package.json 的放置順序則決定了 node_modules 的依賴結構：

先依賴buffer2：

先依賴buffer：

另外，爲了讓開發者在安全的前提下使用最新的依賴包，我們在 package.json 通常只會鎖定大版本，這意味着在某些依賴包小版本更新後，同樣可能造成依賴結構的改動，依賴結構的不確定性可能會給程序帶來不可預知的問題。

3.3 Lock文件

爲了解決 npm install 的不確定性問題，在 npm 5.x 版本新增了 package-lock.json 文件，而安裝方式還沿用了 npm 3.x 的扁平化的方式。

package-lock.json 的作用是鎖定依賴結構，即只要你目錄下有 package-lock.json 文件，那麼你每次執行 npm install 後生成的 node_modules 目錄結構一定是完全相同的。

例如，我們有如下的依賴結構：

{
  "name": "my-app",
  "dependencies": {
    "buffer": "^5.4.3",
    "ignore": "^5.1.4",
    "base64-js": "1.0.1",
  }
}

在執行 npm install 後生成的 package-lock.json 如下：

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "base64-js": {
      "version": "1.0.1",
      "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
      "integrity": "sha1-aSbRsZT7xze47tUTdW3i/Np+pAg="
    },
    "buffer": {
      "version": "5.4.3",
      "resolved": "https://registry.npmjs.org/buffer/-/buffer-5.4.3.tgz",
      "integrity": "sha512-zvj65TkFeIt3i6aj5bIvJDzjjQQGs4o/sNoezg1F1kYap9Nu2jcUdpwzRSJTHMMzG0H7bZkn4rNQpImhuxWX2A==",
      "requires": {
        "base64-js": "^1.0.2",
        "ieee754": "^1.1.4"
      },
      "dependencies": {
        "base64-js": {
          "version": "1.3.1",
          "resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.3.1.tgz",
          "integrity": "sha512-mLQ4i2QO1ytvGWFWmcngKO//JXAQueZvwEKtjgQFM4jIK0kU+ytMfplL8j+n5mspOfjHwoAg+9yhb7BwAHm36g=="
        }
      }
    },
    "ieee754": {
      "version": "1.1.13",
      "resolved": "https://registry.npmjs.org/ieee754/-/ieee754-1.1.13.tgz",
      "integrity": "sha512-4vf7I2LYV/HaWerSo3XmlMkp5eZ83i+/CDluXi/IGTs/O1sejBNhTtnxzmRZfvOUqj7lZjqHkeTvpgSFDlWZTg=="
    },
    "ignore": {
      "version": "5.1.4",
      "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.1.4.tgz",
      "integrity": "sha512-MzbUSahkTW1u7JpKKjY7LCARd1fU5W2rLdxlM4kdkayuCwZImjkpluF9CM1aLewYJguPDqewLam18Y6AU69A8A=="
    }
  }
}

我們來具體看看上面的結構：

最外面的兩個屬性 name 、version 同 package.json 中的 name 和 version ，用於描述當前包名稱和版本。

dependencies 是一個對象，對象和 node_modules 中的包結構一一對應，對象的 key 爲包名稱，值爲包的一些描述信息：

• version：包版本 —— 這個包當前安裝在 node_modules 中的版本
• resolved：包具體的安裝來源
• integrity：包 hash 值，基於 Subresource Integrity 來驗證已安裝的軟件包是否被改動過、是否已失效
• requires：對應子依賴的依賴，與子依賴的 package.json 中 dependencies的依賴項相同。
• dependencies：結構和外層的 dependencies 結構相同，存儲安裝在子依賴 node_modules 中的依賴包。

這裏注意，並不是所有的子依賴都有 dependencies 屬性，只有子依賴的依賴和當前已安裝在根目錄的 node_modules 中的依賴衝突之後，纔會有這個屬性。

例如，回顧下上面的依賴關係：

我們在 my-app 中依賴的 [email protected] 版本與 buffer 中依賴的 base64-js@^1.0.2 發生衝突，所以 [email protected] 需要安裝在 buffer 包的 node_modules 中，對應了 package-lock.json 中 buffer 的 dependencies 屬性。這也對應了 npm 對依賴的扁平化處理方式。

所以，根據上面的分析， package-lock.json 文件 和 node_modules 目錄結構是一一對應的，即項目目錄下存在 package-lock.json 可以讓每次安裝生成的依賴目錄結構保持相同。

另外，項目中使用了 package-lock.json 可以顯著加速依賴安裝時間。

我們使用 npm i --timing=true --loglevel=verbose 命令可以看到 npm install 的完整過程，下面我們來對比下使用 lock 文件和不使用 lock 文件的差別。在對比前先清理下npm 緩存。

不使用 lock 文件：

使用 lock 文件：

可見， package-lock.json 中已經緩存了每個包的具體版本和下載鏈接，不需要再去遠程倉庫進行查詢，然後直接進入文件完整性校驗環節，減少了大量網絡請求。

使用建議

開發系統應用時，建議把 package-lock.json 文件提交到代碼版本倉庫，從而保證所有團隊開發者以及 CI 環節可以在執行 npm install 時安裝的依賴版本都是一致的。

在開發一個 npm包 時，你的 npm包 是需要被其他倉庫依賴的，由於上面我們講到的扁平安裝機制，如果你鎖定了依賴包版本，你的依賴包就不能和其他依賴包共享同一 semver 範圍內的依賴包，這樣會造成不必要的冗餘。所以我們不應該把package-lock.json 文件發佈出去（ npm 默認也不會把 package-lock.json 文件發佈出去）。

3.4 緩存

在執行 npm install 或 npm update命令下載依賴後，除了將依賴包安裝在node_modules 目錄下外，還會在本地的緩存目錄緩存一份。

通過 npm config get cache 命令可以查詢到：在 Linux 或 Mac 默認是用戶主目錄下的 .npm/_cacache 目錄。

在這個目錄下又存在兩個目錄：content-v2、index-v5，content-v2 目錄用於存儲 tar包的緩存，而index-v5目錄用於存儲tar包的 hash。

npm 在執行安裝時，可以根據 package-lock.json 中存儲的 integrity、version、name 生成一個唯一的 key 對應到 index-v5 目錄下的緩存記錄，從而找到 tar包的 hash，然後根據 hash 再去找緩存的 tar包直接使用。

我們可以找一個包在緩存目錄下搜索測試一下，在 index-v5 搜索一下包路徑：

grep "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz" -r index-v5

然後我們將json格式化：

{
  "key": "pacote:version-manifest:https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz:sha1-aSbRsZT7xze47tUTdW3i/Np+pAg=",
  "integrity": "sha512-C2EkHXwXvLsbrucJTRS3xFHv7Mf/y9klmKDxPTE8yevCoH5h8Ae69Y+/lP+ahpW91crnzgO78elOk2E6APJfIQ==",
  "time": 1575554308857,
  "size": 1,
  "metadata": {
    "id": "[email protected]",
    "manifest": {
      "name": "base64-js",
      "version": "1.0.1",
      "engines": {
        "node": ">= 0.4"
      },
      "dependencies": {},
      "optionalDependencies": {},
      "devDependencies": {
        "standard": "^5.2.2",
        "tape": "4.x"
      },
      "bundleDependencies": false,
      "peerDependencies": {},
      "deprecated": false,
      "_resolved": "https://registry.npmjs.org/base64-js/-/base64-js-1.0.1.tgz",
      "_integrity": "sha1-aSbRsZT7xze47tUTdW3i/Np+pAg=",
      "_shasum": "6926d1b194fbc737b8eed513756de2fcda7ea408",
      "_shrinkwrap": null,
      "bin": null,
      "_id": "[email protected]"
    },
    "type": "finalized-manifest"
  }
}

上面的 _shasum 屬性 6926d1b194fbc737b8eed513756de2fcda7ea408 即爲 tar 包的 hash， hash的前幾位 6926 即爲緩存的前兩層目錄，我們進去這個目錄果然找到的壓縮後的依賴包：

以上的緩存策略是從 npm v5 版本開始的，在 npm v5 版本之前，每個緩存的模塊在 ~/.npm 文件夾中以模塊名的形式直接存儲，儲存結構是{cache}/{name}/{version}。

npm 提供了幾個命令來管理緩存數據：

• npm cache add：官方解釋說這個命令主要是 npm 內部使用，但是也可以用來手動給一個指定的 package 添加緩存。
• npm cache clean：刪除緩存目錄下的所有數據，爲了保證緩存數據的完整性，需要加上 --force 參數。
• npm cache verify：驗證緩存數據的有效性和完整性，清理垃圾數據。

基於緩存數據，npm 提供了離線安裝模式，分別有以下幾種：

• --prefer-offline： 優先使用緩存數據，如果沒有匹配的緩存數據，則從遠程倉庫下載。
• --prefer-online： 優先使用網絡數據，如果網絡數據請求失敗，再去請求緩存數據，這種模式可以及時獲取最新的模塊。
• --offline： 不請求網絡，直接使用緩存數據，一旦緩存數據不存在，則安裝失敗。

3.5 文件完整性

上面我們多次提到了文件完整性，那麼什麼是文件完整性校驗呢？

在下載依賴包之前，我們一般就能拿到 npm 對該依賴包計算的 hash 值，例如我們執行 npm info 命令，緊跟 tarball(下載鏈接) 的就是 shasum(hash) ：

用戶下載依賴包到本地後，需要確定在下載過程中沒有出現錯誤，所以在下載完成之後需要在本地在計算一次文件的 hash 值，如果兩個 hash 值是相同的，則確保下載的依賴是完整的，如果不同，則進行重新下載。

3.6 整體流程

好了，我們再來整體總結下上面的流程：

• 檢查 .npmrc 文件：優先級爲：項目級的 .npmrc 文件 > 用戶級的 .npmrc 文件> 全局級的 .npmrc 文件 > npm 內置的 .npmrc 文件

• 檢查項目中有無 lock 文件。

• 無 lock 文件：

  • 從 npm 遠程倉庫獲取包信息
  • 根據 package.json 構建依賴樹，構建過程：
    • 構建依賴樹時，不管其是直接依賴還是子依賴的依賴，優先將其放置在 node_modules 根目錄。
    • 當遇到相同模塊時，判斷已放置在依賴樹的模塊版本是否符合新模塊的版本範圍，如果符合則跳過，不符合則在當前模塊的 node_modules 下放置該模塊。
    • 注意這一步只是確定邏輯上的依賴樹，並非真正的安裝，後面會根據這個依賴結構去下載或拿到緩存中的依賴包
  • 在緩存中依次查找依賴樹中的每個包
    • 不存在緩存：
      • 從 npm 遠程倉庫下載包
      • 校驗包的完整性
      • 校驗不通過：
        • 重新下載
      • 校驗通過：
        • 將下載的包複製到 npm 緩存目錄
        • 將下載的包按照依賴結構解壓到 node_modules
    • 存在緩存：將緩存按照依賴結構解壓到 node_modules
  • 將包解壓到 node_modules
  • 生成 lock 文件

• 有 lock 文件：

  • 檢查 package.json 中的依賴版本是否和 package-lock.json 中的依賴有衝突。
  • 如果沒有衝突，直接跳過獲取包信息、構建依賴樹過程，開始在緩存中查找包信息，後續過程相同

上面的過程簡要描述了 npm install 的大概過程，這個過程還包含了一些其他的操作，例如執行你定義的一些生命週期函數，你可以執行 npm install package --timing=true --loglevel=verbose 來查看某個包具體的安裝流程和細節。

3.7 yarn

yarn 是在 2016 年發佈的，那時 npm 還處於 V3 時期，那時候還沒有 package-lock.json 文件，就像上面我們提到的：不穩定性、安裝速度慢等缺點經常會受到廣大開發者吐槽。此時，yarn 誕生：

上面是官網提到的 yarn 的優點，在那個時候還是非常吸引人的。當然，後來 npm 也意識到了自己的問題，進行了很多次優化，在後面的優化（lock文件、緩存、默認-s…）中，我們多多少少能看到 yarn 的影子，可見 yarn 的設計還是非常優秀的。

yarn 也是採用的是 npm v3 的扁平結構來管理依賴，安裝依賴後默認會生成一個 yarn.lock 文件，還是上面的依賴關係，我們看看 yarn.lock 的結構：

# THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY.
# yarn lockfile v1


[email protected]:
  version "1.0.1"
  resolved "https://registry.yarnpkg.com/base64-js/-/base64-js-1.0.1.tgz#6926d1b194fbc737b8eed513756de2fcda7ea408"
  integrity sha1-aSbRsZT7xze47tUTdW3i/Np+pAg=

base64-js@^1.0.2:
  version "1.3.1"
  resolved "https://registry.yarnpkg.com/base64-js/-/base64-js-1.3.1.tgz#58ece8cb75dd07e71ed08c736abc5fac4dbf8df1"
  integrity sha512-mLQ4i2QO1ytvGWFWmcngKO//JXAQueZvwEKtjgQFM4jIK0kU+ytMfplL8j+n5mspOfjHwoAg+9yhb7BwAHm36g==

buffer@^5.4.3:
  version "5.4.3"
  resolved "https://registry.yarnpkg.com/buffer/-/buffer-5.4.3.tgz#3fbc9c69eb713d323e3fc1a895eee0710c072115"
  integrity sha512-zvj65TkFeIt3i6aj5bIvJDzjjQQGs4o/sNoezg1F1kYap9Nu2jcUdpwzRSJTHMMzG0H7bZkn4rNQpImhuxWX2A==
  dependencies:
    base64-js "^1.0.2"
    ieee754 "^1.1.4"

ieee754@^1.1.4:
  version "1.1.13"
  resolved "https://registry.yarnpkg.com/ieee754/-/ieee754-1.1.13.tgz#ec168558e95aa181fd87d37f55c32bbcb6708b84"
  integrity sha512-4vf7I2LYV/HaWerSo3XmlMkp5eZ83i+/CDluXi/IGTs/O1sejBNhTtnxzmRZfvOUqj7lZjqHkeTvpgSFDlWZTg==

ignore@^5.1.4:
  version "5.1.4"
  resolved "https://registry.yarnpkg.com/ignore/-/ignore-5.1.4.tgz#84b7b3dbe64552b6ef0eca99f6743dbec6d97adf"
  integrity sha512-MzbUSahkTW1u7JpKKjY7LCARd1fU5W2rLdxlM4kdkayuCwZImjkpluF9CM1aLewYJguPDqewLam18Y6AU69A8A==

可見其和 package-lock.json 文件還是比較類似的，還有一些區別就是：

• package-lock.json 使用的是 json 格式，yarn.lock 使用的是一種自定義格式
• yarn.lock 中子依賴的版本號不是固定的，意味着單獨又一個 yarn.lock 確定不了 node_modules 目錄結構，還需要和 package.json 文件進行配合。而 package-lock.json 只需要一個文件即可確定。

yarn 的緩策略看起來和 npm v5 之前的很像，每個緩存的模塊被存放在獨立的文件夾，文件夾名稱包含了模塊名稱、版本號等信息。使用命令 yarn cache dir 可以查看緩存數據的目錄：

yarn 默認使用 prefer-online 模式，即優先使用網絡數據，如果網絡數據請求失敗，再去請求緩存數據。

參考

• https://juejin.im/post/5a6008c2f265da3e5033cd93
• https://www.zhihu.com/question/305539244/answer/551386426
• https://zhuanlan.zhihu.com/p/37285173
• https://semver.org/lang/zh-CN/
• http://deadhorse.me/nodejs/2014/04/27/semver-in-nodejs.html
• http://caibaojian.com/npm/files/package.json.html

小結

希望閱讀完本篇文章能對你有如下幫助：

• 瞭解 pacakge.json 中的各項詳細配置從而對項目工程化配置有更進一步的見解
• 掌握 npm 的版本管理機制，能合理配置依賴版本
• 理解 npm install 安裝原理，能合理運用 npm緩存、package-lock.json

文中如有錯誤，歡迎在評論區指正，如果這篇文章幫助到了你，歡迎點贊和關注。

想閱讀更多優質文章、可關注我的github博客，你的star✨、點贊和關注是我持續創作的動力！

推薦關注我的微信公衆號【code祕密花園】，每天推送高質量文章，我們一起交流成長。