摘要：請(qǐng)注意，在版本號(hào)之前有個(gè)字符。理論上，次版本號(hào)的變化并不會(huì)影響向后兼容性。雖然可以通過(guò)命令關(guān)閉在版本號(hào)前面使用的默認(rèn)行為，但這個(gè)只會(huì)影響頂級(jí)依賴(lài)關(guān)系。

本文作者對(duì)比了當(dāng)前主流的包管理工具npm、yarn、pnpm之間的區(qū)別，并提出了合適的使用建議，以下為譯文：

npm是Node.js能夠如此成功的主要原因之一。npm團(tuán)隊(duì)做了很多的工作，以確保npm保持向后兼容，并在不同的環(huán)境中保持一致。

npm是圍繞著語(yǔ)義版本控制（semver）的思想而設(shè)計(jì)的，下面是從他們的網(wǎng)站摘抄過(guò)來(lái)的：

給定一個(gè)版本號(hào)：主版本號(hào).次版本號(hào).補(bǔ)丁版本號(hào)， 以下這三種情況需要增加相應(yīng)的版本號(hào):

主版本號(hào)： 當(dāng)API發(fā)生改變，并與之前的版本不兼容的時(shí)候

次版本號(hào)： 當(dāng)增加了功能，但是向后兼容的時(shí)候

補(bǔ)丁版本號(hào)： 當(dāng)做了向后兼容的缺陷修復(fù)的時(shí)候

npm使用一個(gè)名為package.json的文件，用戶(hù)可以通過(guò)npm install --save命令把項(xiàng)目里所有的依賴(lài)項(xiàng)保存在這個(gè)文件里。

例如，運(yùn)行npm install --save lodash會(huì)將以下幾行添加到package.json文件中。

"dependencies": {
    "lodash": "^4.17.4"
}

請(qǐng)注意，在版本號(hào)lodash之前有個(gè)^字符。這個(gè)字符告訴npm，安裝主版本等于4的任意一個(gè)版本即可。所以如果我現(xiàn)在運(yùn)行npm進(jìn)行安裝，npm將安裝lodash的主版本為4的最新版，可能是 [email protected]（@是npm約定用來(lái)確定包名的指定版本的）。你可以在此處查看所有支持的字符：https://docs.npmjs.com/misc/semver。

理論上，次版本號(hào)的變化并不會(huì)影響向后兼容性。因此，安裝最新版的依賴(lài)庫(kù)應(yīng)該是能正常工作的，而且能引入自4.17.4版本以后的重要錯(cuò)誤和安全方面的修復(fù)。

但是，另一方面，即使不同的開(kāi)發(fā)人員使用了相同的package.json文件，在他們自己的機(jī)器上也可能會(huì)安裝同一個(gè)庫(kù)的不同種版本，這樣就會(huì)存在潛在的難以調(diào)試的錯(cuò)誤和“在我的電腦上…”的情形。

大多數(shù)npm庫(kù)都嚴(yán)重依賴(lài)于其他npm庫(kù)，這會(huì)導(dǎo)致嵌套依賴(lài)關(guān)系，并增加無(wú)法匹配相應(yīng)版本的幾率。

雖然可以通過(guò)npm config set save-exact true命令關(guān)閉在版本號(hào)前面使用^的默認(rèn)行為，但這個(gè)只會(huì)影響頂級(jí)依賴(lài)關(guān)系。由于每個(gè)依賴(lài)的庫(kù)都有自己的package.json文件，而在它們自己的依賴(lài)關(guān)系前面可能會(huì)有^符號(hào)，所以無(wú)法通過(guò)package.json文件為嵌套依賴(lài)的內(nèi)容提供保證。

為了解決這個(gè)問(wèn)題，npm提供了shrinkwrap命令。此命令將生成一個(gè)npm-shrinkwrap.json文件，為所有庫(kù)和所有嵌套依賴(lài)的庫(kù)記錄確切的版本。

然而，即使存在npm-shrinkwrap.json這個(gè)文件，npm也只會(huì)鎖定庫(kù)的版本，而不是庫(kù)的內(nèi)容。即便npm現(xiàn)在也能阻止用戶(hù)多次重復(fù)發(fā)布庫(kù)的同一版本，但是npm管理員仍然具有強(qiáng)制更新某些庫(kù)的權(quán)力。

這是引用自shrinkwrap文檔的內(nèi)容：

如果你希望鎖定包中的特定字節(jié)，比如是為了保證能正確地重新部署或構(gòu)建，那么你應(yīng)該在源代碼控制中檢查依賴(lài)關(guān)系，或者采取一些其他的機(jī)制來(lái)校驗(yàn)內(nèi)容，而不是靠校驗(yàn)版本。

npm 2會(huì)安裝每一個(gè)包所依賴(lài)的所有依賴(lài)項(xiàng)。如果我們有這么一個(gè)項(xiàng)目，它依賴(lài)項(xiàng)目A，項(xiàng)目A依賴(lài)項(xiàng)目B，項(xiàng)目B依賴(lài)項(xiàng)目C，那么依賴(lài)樹(shù)將如下所示：

node_modules
- package-A
-- node_modules
--- package-B
----- node_modules
------ package-C
-------- some-really-really-really-long-file-name-in-package-c.js

這個(gè)結(jié)構(gòu)可能會(huì)很長(zhǎng)。這對(duì)于基于Unix的操作系統(tǒng)來(lái)說(shuō)只不過(guò)是一個(gè)小煩惱，但對(duì)于Windows來(lái)說(shuō)卻是個(gè)破壞性的東西，因?yàn)橛泻芏喑绦驘o(wú)法處理超過(guò)260個(gè)字符的文件路徑名。

npm 3采用了扁平依賴(lài)關(guān)系樹(shù)來(lái)解決這個(gè)問(wèn)題，所以我們的3個(gè)項(xiàng)目結(jié)構(gòu)現(xiàn)在看起來(lái)如下所示：

node_modules
- package-A
- package-B
- package-C
-- some-file-name-in-package-c.js

這樣，一個(gè)原來(lái)很長(zhǎng)的文件路徑名就從./node_modules/package-A/node_modules/package-B/node-modules/some-file-name-in-package-c.js變成了/node_modules/some-file-name-in-package-c.js。

你可以在這里閱讀到更多有關(guān)NPM 3依賴(lài)解析的工作原理。

這種方法的缺點(diǎn)是，npm必須首先遍歷所有的項(xiàng)目依賴(lài)關(guān)系，然后再?zèng)Q定如何生成扁平的node_modules目錄結(jié)構(gòu)。npm必須為所有使用到的模塊構(gòu)建一個(gè)完整的依賴(lài)關(guān)系樹(shù)，這是一個(gè)耗時(shí)的操作，是npm安裝速度慢的一個(gè)很重要的原因。

由于我沒(méi)有詳細(xì)了解npm的變化，所以我想當(dāng)然的以為每次運(yùn)行npm install命令時(shí)，NPM都得從互聯(lián)網(wǎng)上下載所有內(nèi)容。

但是，我錯(cuò)了，npm是有本地緩存的，它保存了已經(jīng)下載的每個(gè)版本的壓縮包。本地緩存的內(nèi)容可以通過(guò)npm cache ls命令進(jìn)行查看。本地緩存的設(shè)計(jì)有助于減少安裝時(shí)間。

總而言之，npm是一個(gè)成熟、穩(wěn)定、并且有趣的包管理器。

Yarn發(fā)布于2016年10月，并在Github上迅速擁有了2.4萬(wàn)個(gè)Star。而npm只有1.2萬(wàn)個(gè)Star。這個(gè)項(xiàng)目由一些高級(jí)開(kāi)發(fā)人員維護(hù)，包括了Sebastian McKenzie（Babel.js）和Yehuda Katz（Ember.js、Rust、Bundler等）。

從我搜集到的情況來(lái)看，Yarn一開(kāi)始的主要目標(biāo)是解決上一節(jié)中描述的由于語(yǔ)義版本控制而導(dǎo)致的npm安裝的不確定性問(wèn)題。雖然可以使用npm shrinkwrap來(lái)實(shí)現(xiàn)可預(yù)測(cè)的依賴(lài)關(guān)系樹(shù)，但它并不是默認(rèn)選項(xiàng)，而是取決于所有的開(kāi)發(fā)人員知道并且啟用這個(gè)選項(xiàng)。

Yarn采取了不同的做法。每個(gè)yarn安裝都會(huì)生成一個(gè)類(lèi)似于npm-shrinkwrap.json的yarn.lock文件，而且它是默認(rèn)創(chuàng)建的。除了常規(guī)信息之外，yarn.lock文件還包含要安裝的內(nèi)容的校驗(yàn)和，以確保使用的庫(kù)的版本相同。

由于yarn是嶄新的經(jīng)過(guò)重新設(shè)計(jì)的npm客戶(hù)端，它能讓開(kāi)發(fā)人員并行化處理所有必須的操作，并添加了一些其他改進(jìn)，這使得運(yùn)行速度得到了顯著的提升，整個(gè)安裝時(shí)間也變得更少。我估計(jì)，速度提升是yarn受歡迎的主要原因。

像npm一樣，yarn使用本地緩存。與npm不同的是，yarn無(wú)需互聯(lián)網(wǎng)連接就能安裝本地緩存的依賴(lài)項(xiàng)，它提供了離線(xiàn)模式。這個(gè)功能在2012年的npm項(xiàng)目中就被提出來(lái)過(guò)，但一直沒(méi)有實(shí)現(xiàn)。

yarn還提供了一些其他改進(jìn)，例如，它允許合并項(xiàng)目中使用到的所有的包的許可證，這一點(diǎn)讓人很高興。

一個(gè)有趣的事情是，yarn文檔的態(tài)度開(kāi)始針對(duì)npm發(fā)生改變，因?yàn)閥arn項(xiàng)目變得流行起來(lái)。

最開(kāi)始的yarn公告是這么介紹yarn的安裝的：

*最簡(jiǎn)單的入門(mén)方法是運(yùn)行：?

npm install -g yarn?
yarn*

現(xiàn)在的yarn安裝頁(yè)面是這么說(shuō)的：

注意：通常情況下不建議通過(guò)npm進(jìn)行安裝。npm安裝是非確定性的，程序包沒(méi)有簽名，并且npm除了做了基本的SHA1哈希之外不執(zhí)行任何完整性檢查，這給安裝系統(tǒng)程序帶來(lái)了安全風(fēng)險(xiǎn)。

基于這些原因，強(qiáng)烈建議你通過(guò)最適合于你的操作系統(tǒng)的安裝方法來(lái)安裝yarn。

以這種速度發(fā)展下去的話(huà)，如果yarn要宣布他們自己的registry，讓開(kāi)發(fā)者慢慢淘汰npm的話(huà)，我們一點(diǎn)都不會(huì)感到驚訝。

看起來(lái)似乎要感謝yarn，npm終于意識(shí)到他們需要更加關(guān)注一些大家強(qiáng)烈要求的問(wèn)題了。當(dāng)我在審核我之前提到的強(qiáng)烈要求的“離線(xiàn)”功能時(shí)，我注意到這個(gè)需求正在被積極地修復(fù)之中。

正如我所提到的，在pnpm的作者Zoltan Kochan發(fā)表了“為什么要用pnpm？”之后，我才知道pnpm。

我不會(huì)介紹太多的細(xì)節(jié)（因?yàn)檫@篇文章已經(jīng)發(fā)布很久了），但是你可以查看我的最初的帖子來(lái)尋找更多的內(nèi)容，同時(shí)在Twitter上加入討論。

但是

我想指出的是，pnpm運(yùn)行起來(lái)非常的快，甚至超過(guò)了npm和yarn。

為什么這么快呢？ 因?yàn)樗捎昧艘环N巧妙的方法，利用硬鏈接和符號(hào)鏈接來(lái)避免復(fù)制所有本地緩存源文件，這是yarn的最大的性能弱點(diǎn)之一。

使用鏈接并不容易，會(huì)帶來(lái)一堆問(wèn)題需要考慮。

正如Sebastian在Twitter上指出的那樣，他最初是打算在yarn中使用符號(hào)鏈接的，但是由于其他一些原因放棄了它。

同時(shí)，正如在Github上擁有2000多個(gè)Star那樣，pnpm能夠?yàn)樵S多人所用。

此外，截至2017年3月，它繼承了yarn的所有優(yōu)點(diǎn)，包括離線(xiàn)模式和確定性安裝。

我認(rèn)為yarn和pnpm的開(kāi)發(fā)人員做了一個(gè)驚人的工作。我個(gè)人喜歡的是確定性安裝，因?yàn)槲蚁矚g控制，我不喜歡驚喜。

無(wú)論這場(chǎng)競(jìng)爭(zhēng)的結(jié)果是什么，我很感謝yarn在npm的腳下點(diǎn)了一把火，提供了另外一個(gè)選擇。

我確信yarn是一個(gè)更安全的選擇，但是pnpm可能是一些測(cè)試用例的更好的選擇。例如，它可以在運(yùn)行大量集成測(cè)試并希望盡可能快地安裝依賴(lài)關(guān)系的中小型團(tuán)隊(duì)中發(fā)揮作用。

最后，我認(rèn)為，npm仍然提供了一個(gè)非常有用的解決方案，支持大量的測(cè)試用例。大多數(shù)開(kāi)發(fā)人員使用原始npm客戶(hù)端仍然可以做得很好。

react-native技術(shù)的優(yōu)劣

學(xué)習(xí)React Native必看的幾個(gè)開(kāi)源項(xiàng)目

手把手教你React Native 實(shí)戰(zhàn)之開(kāi)山篇《一》

?手把手教你React Native實(shí)戰(zhàn)從 React到Rn《二》