本文從三個角度：package.json、版本管理、依賴安裝結合具體實例對 npm 的包管理機制進行了詳細分析。
我之前發過這三篇文章，實際上下面三篇文章都是圍繞包版本管理來寫的，把他們串聯起來可以更全面的看到整個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" : "lisqPersion@163.com",
"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
依賴包名稱:DWONLOAD_URL
依賴包名稱:LOCAL_PATH
依賴包名稱:GITHUB_URL
依賴包名稱: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
dependenciesdependencies 指定了項目運行所依賴的模塊，開發環境和生產環境的依賴模塊都可以配置到這裡，例如
"dependencies": {
"lodash": "^4.17.13",
"moment": "^2.24.0",
}
有一些包有可能你只是在開發環境中用到，例如你用於檢測代碼規範的 eslint ,用於進行測試的 jest ，用戶使用你的包時即使不安裝這些依賴也可以正常運行，反而安裝他們會耗費更多的時間和資源，所以你可以把這些依賴添加到 devDependencies 中，這些依賴照樣會在你本地進行 npm install 時被安裝和管理，但是不會被安裝到生產環境：
"devDependencies": {
"jest": "^24.3.1",
"eslint": "^6.1.0",
}
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"]
{
"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 文件。
manman 命令是 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。
configconfig 欄位用於配置腳本中使用的環境變量，例如下面的配置，可以在腳本中使用process.env.npm_package_config_port進行獲取。
{
"config" : { "port" : "8080" }
}
如果你的 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
先行版本當某個版本改動比較大、並非穩定而且可能無法滿足預期的兼容性需求時，你可能要先發布一個先行版本。
先行版本號可以加到「主版本號.次版本號.修訂號」的後面，先加上一個連接號再加上一連串以句點分隔的標識符和版本編譯信息。
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.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）
再來看看後面兩個，版本號中引用了 ~ 和 ^ 符號：
在 package.json 文件中最常見的應該是 "yargs": "^14.0.0" 這種格式的 依賴, 因為我們在使用 npm install package 安裝包時，npm 默認安裝當前最新版本，然後在所安裝的版本號前加 ^ 號。
注意，當主版本號為 0 的情況，會被認為是一個不穩定版本，情況與上面不同：
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的版本在5.6以上，確保默認開啟 package-lock.json 文件。
由初始化成員執行 npm inatall 後，將 package-lock.json 提交到遠程倉庫。不要直接提交 node_modules到遠程倉庫。
定期執行 npm update 升級依賴，並提交 lock 文件確保其他成員同步更新依賴，不要手動更改 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 將非常龐大，嵌套層級非常之深：
為了解決以上問題，NPM 在 3.x 版本做了一次較大更新。其將早期的嵌套結構改為扁平結構：
還是上面的依賴結構，我們在執行 npm install 後將得到下面的目錄結構：
此時我們若在模塊中又依賴了 base64-js@1.0.1 版本：
{
"name": "my-app",
"dependencies": {
"buffer": "^5.4.3",
"ignore": "^5.1.4",
"base64-js": "1.0.1",
}
}
此時，我們在執行 npm install 後將得到下面的目錄結構：
對應的，如果我們在項目代碼中引用了一個模塊，模塊查找流程如下：
假設我們又依賴了一個包 buffer2@^5.4.3，而它依賴了包 base64-js@1.0.3，則此時的安裝結構是下面這樣的：
所以 npm 3.x 版本並未完全解決老版本的模塊冗餘問題，甚至還會帶來新的問題。
試想一下，你的APP假設沒有依賴 base64-js@1.0.1 版本，而你同時依賴了依賴不同 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 中依賴的 base64-js@1.0.1 版本與 buffer 中依賴的 base64-js@^1.0.2 發生衝突，所以 base64-js@1.0.1 需要安裝在 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": "base64-js@1.0.1",
"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": "base64-js@1.0.1"
},
"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 整體流程好了，我們再來整體總結下上面的流程：
上面的過程簡要描述了 npm install 的大概過程，這個過程還包含了一些其他的操作，例如執行你定義的一些生命周期函數，你可以執行 npm install package --timing=true --loglevel=verbose 來查看某個包具體的安裝流程和細節。
3.7 yarnyarn 是在 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
base64-js@1.0.1:
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 文件還是比較類似的，還有一些區別就是：
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