摘要：第一個(gè)主要的包管理器在被引用后不久就搭建起來了，并且迅速成為世界上最受歡迎的包管理器之一。簡(jiǎn)介是一款新的包管理器，在取代客戶端和其他包管理器現(xiàn)有工作流的同時(shí)，又保留了對(duì)代理的兼容性。

在JavaScript社區(qū)，工程師們分享了成百上千的代碼段，我們不用自己從頭編寫基礎(chǔ)組件、類庫或者框架。反過來，每段代碼又或許依賴于其它的代碼段，而這些依賴就是通過 package managers(包管理器) 來管理的。最流行的JavaScript包管理器就是 npm客戶端了，它可以訪問在npm注冊(cè)的 300,000 多個(gè)安裝包。超出500萬的工程師使用npm注冊(cè)，每個(gè)月的下載量高達(dá) 50 億。

我們成功地在Facebook用了幾年的npm客戶端。但隨著代碼庫規(guī)模的擴(kuò)大以及開發(fā)者人數(shù)的增加，我們碰到了連貫性，安全性 和 性能 方面的問題。在迎難而上解決一個(gè)又一個(gè)的問題后，我們著手構(gòu)建一個(gè)新的方案，來幫助我們更可靠地管理我們的依賴。執(zhí)行這項(xiàng)工作的產(chǎn)品名為 Yarn -- 它是一個(gè)快速、可靠、安全的、可替換的npm客戶端。

我們很高興地宣布與Exponent、 Google 和 Tilde 合作的 Yarn 開源版本。有了 Yarn之后, 軟件工程師們?nèi)匀豢梢栽L問npm庫，而且可以更快地安裝npm包，并且跨機(jī)器或者在安全的離線環(huán)境下一致性地管理依賴。Yarn 使得工程師可以更加快速開發(fā)，并且信心百倍地使用分享的代碼庫，從而專注于更重要的事情 -- 構(gòu)建新的產(chǎn)品和特性。

在還沒包管理器的時(shí)候，JS工程師常常依賴于存儲(chǔ)在他們項(xiàng)目中或者放在CDN上面的少量代碼段。第一個(gè)主要的JS包管理器 npm 在Node.js被引用后不久就搭建起來了，并且迅速成為世界上最受歡迎的包管理器之一。上千個(gè)新的開源項(xiàng)目被建立了，工程師們也比以往分享了更多的代碼。

很多Facebook的項(xiàng)目（如React），都是依賴于npm包。然而，隨著內(nèi)部規(guī)模的擴(kuò)大，我們都遇到了這樣的問題：當(dāng)跨機(jī)器或用戶安裝依賴時(shí)，拉取依賴包消耗的時(shí)間較長(zhǎng)，也考慮到安全性的問題，因?yàn)閚pm客戶端會(huì)自動(dòng)執(zhí)行這些依賴包里面的代碼。我們嘗試去解決這些問題，卻發(fā)現(xiàn)這些問題還不斷地衍生出新的問題。

起初，按照指定的最佳實(shí)踐，我們只是檢入 package.json 并且要求開發(fā)者手動(dòng)地執(zhí)行npm install 。這足以滿足軟件工程師的開發(fā)需求，但在我們持續(xù)集成的環(huán)境中就崩潰了，因?yàn)樘幱诎踩院涂煽啃缘目紤]，這種環(huán)境需要沙箱化，并且切斷網(wǎng)絡(luò)服務(wù)。

我們的第二個(gè)方案是檢入所有進(jìn)入代碼庫的 node_modules。這種做法雖然奏效，卻使得一些原本簡(jiǎn)單的操作變得相當(dāng)困難。舉個(gè)例子，更新一個(gè)小版本 babel 就會(huì)生成一個(gè)80萬行的commit，這對(duì)于無效的UTF8字節(jié)串、窗口的行尾退出符號(hào)，非 png-crushed 的圖片等都很難處理。工程師們經(jīng)常都要花上一整天的時(shí)間，才能把改動(dòng)的代碼合并到 node_modules中。我們掌控源代碼的團(tuán)隊(duì)也指出：檢查 node_modules 文件是對(duì)大量元數(shù)據(jù)負(fù)責(zé)任的做法。React Native 的 package.json 文件目前只是列出了68個(gè)依賴，但執(zhí)行 npm install 之后，node_modules 目錄下就生成了121，358個(gè)文件。

我們做了最后一個(gè)嘗試來規(guī)劃npm客戶端的大小，使之可以和開發(fā)者的數(shù)量以及我們所需的代碼量來協(xié)調(diào)工作。我們覺得壓縮整個(gè) node_modules 文件夾，并且把它上傳到內(nèi)部的CDN，這樣開發(fā)者和我們持續(xù)的集成系統(tǒng)都可以下載，并一致地提取文件。這使得我們可以從原文件中刪除成千上百個(gè)文件。但是，這樣做軟件開發(fā)者不僅是拉取還是構(gòu)建新代碼，都需要網(wǎng)絡(luò)服務(wù)。

我們也必須應(yīng)對(duì) npm shrinkwrap 功能所帶來的問題，因?yàn)槲覀兺ㄟ^ shrinkwrap 來鎖定版本。npm-shrinkwrap.json 不是默認(rèn)生成的，如果開發(fā)者忘記生成，就會(huì)導(dǎo)致不同步的問題。因此我們寫了一個(gè)工具，來驗(yàn)證安裝包里的文件與 node_modules 中的哪些文件相匹配。npm-shrinkwrap.json 是由大量無序字段組成的 JSON blobs ，所以改變它們就會(huì)生成龐大的、無法 review 的commits。為了緩和這個(gè)問題，我們需要額外添加一個(gè)腳本來區(qū)分所有的條目。

基于 semantic versioning（語義法版本控制） 原則，用npm更新一個(gè)簡(jiǎn)單的依賴, 也會(huì)相應(yīng)更新許多不相關(guān)的依賴。這樣使得每次改變的代碼量大大增加， 而且必須重復(fù)提交 node_modules 或者上傳到CDN這樣的事情，這個(gè)過程對(duì)開發(fā)者來說是不理想的。

我們決定嘗試整體地去看待這個(gè)問題，而不是在npm客戶端繼續(xù)修復(fù)。假如我們嘗試搭建了一個(gè)新的客戶端來處理遇到的這些核心問題又會(huì)怎樣呢？我們倫敦工作室的 Sebastian McKenzie 已經(jīng)開始hack這個(gè)想法，我們也為它的前景而興奮。

隨著這項(xiàng)工作的展開，我們開始和不同領(lǐng)域的工程師交流，并發(fā)現(xiàn)他們也遇到一系列類似的問題，也嘗試了很多相同的解決方案，經(jīng)常都是專注于解決眼下的問題。顯然，通過結(jié)合大家所遇到的問題，我們可以開發(fā)一套共用的方案。在來自Exponent、Google 和 Tilde的工程師的幫助下，我們搭建了Yarn客戶端，并在每個(gè)主要的JS框架上以及Facebook之外的場(chǎng)景測(cè)試和驗(yàn)證了它的性能。今天，我們帶著激動(dòng)的心情來和大家一起分享它。

Yarn 是一款新的包管理器，在取代npm客戶端和其他包管理器現(xiàn)有工作流的同時(shí)，又保留了對(duì)npm代理的兼容性。它擁有與現(xiàn)有的工作流相同的特性，只是操作起來更快、更安全、更可靠。

任何包管理器的主要功能都是去安裝一些依賴模塊 -- 一段服務(wù)于特定的目的代碼 -- 從一個(gè)全局的注冊(cè)到開發(fā)者的本地環(huán)境。包與包之間可能相互依賴，也可能是自己獨(dú)立的。一個(gè)典型的項(xiàng)目的依賴包可能會(huì)有幾十個(gè)、幾百個(gè)或者是上千個(gè)。

這些依賴都是版本化的，而且都是基于 語義版本控制 安裝的。語義版本定義了一套版本的方案，無論是改了一個(gè)API，添加了一個(gè)新特性，還是修復(fù)了一個(gè)bug，都會(huì)在每個(gè)新版本上反映出來。然而，語義版本需要包開發(fā)者確保不出錯(cuò)，因?yàn)樵谝蕾嚊]有鎖定的情況下，新的bug或漏洞都會(huì)被注入到依賴包里面。

在Node環(huán)境下，依賴都放在你項(xiàng)目的 node_modules 文件夾下。然而，這些文件結(jié)構(gòu)或許和實(shí)際的依賴樹不一致，因?yàn)橹貜?fù)的依賴會(huì)被合并到一起。npm客戶端在安裝依賴到 ?node_modules 目錄時(shí)順序不是固定的。這意味著隨著安裝順序的不同，不同開發(fā)者 node_modules 下的目錄結(jié)構(gòu)會(huì)存在差異。這種差異有可能引發(fā)“在我的電腦上是好的”bug，找出這種bug通常是比較耗時(shí)的。

Yarn 通過 yarn.lock 和一個(gè)可靠、確定的算法解決了上面提及的版本控制和安裝順序這些問題。這些鎖定文件為安裝的依賴添加一個(gè)特定的版本號(hào)，并且確保在不同機(jī)器上安裝時(shí) node_modules 目錄結(jié)構(gòu)相同。lockfile 使用簡(jiǎn)明的書寫格式和有序的 key 來確保改動(dòng)盡量小，review起來更加簡(jiǎn)單。

安裝過程可拆分為三個(gè)步驟：

識(shí)別:?開始通過發(fā)送請(qǐng)求并依次查找每個(gè)依賴來識(shí)別其中的依賴關(guān)系。

獲取: 接下來，Yarn 查看全局緩存來確定所需的安裝包是否已經(jīng)下載。如果沒有，Yarn 就抓取壓縮包并把它放在全局的緩存中，既可以做到離線工作，也可以確保以后需要時(shí)無須再次下載。依賴也可以像壓縮包一樣放在源碼中，以便離線安裝。

連接:?最后，Yarn 從全局的緩存中復(fù)制所需的文件放置到本地的 node_modules 目錄下連接起來。

通過明確地拆分這些步驟，得到確定的結(jié)果來實(shí)現(xiàn)并行操作，這樣資源利用得到最大化，安裝速度也大大提升。在Facebook 的一些項(xiàng)目中，Yarn 把安裝速度提升了一個(gè)梯度，從幾分鐘到短短幾秒。Yarn 也使用互斥來確保多個(gè)命令行安裝時(shí)不會(huì)沖突或者互相污染。

Yarn 對(duì)于整個(gè)壓縮包的安裝過程都有嚴(yán)格的保證。你可以控制不同生命周期的腳本來執(zhí)行對(duì)應(yīng)的安裝包。壓縮包 校驗(yàn)和 也被存儲(chǔ)在 lockfile 以確保你每次都能拿到同樣的壓縮包。

除了讓安裝過程更快更可靠，Yarn 還有額外的特性來更好地簡(jiǎn)化依賴管理的工作流。

兼容 npm 和 bower 工作流，并且支持混合注冊(cè)。

能夠限制已安裝模塊的證書以及輸出證書信息。

暴露一個(gè)穩(wěn)定公開的JS API，通過構(gòu)建工具提供抽象的日志記錄。

可讀、最小化、良好的命令行輸出。

我們已經(jīng)在 Facebook 的生產(chǎn)環(huán)境下使用 Yarn 了，也運(yùn)行得相當(dāng)好。它頗有力度地為我們的很多 JavaScript 項(xiàng)目管理了依賴和壓縮包。隨著每次升級(jí)，工程師們已經(jīng)能夠離線搭建，并且加速他們的工作流。你可以在這里 查看不同環(huán)境下 React Native 分別用 Yarn 和 npm 的安裝所消耗的時(shí)間。

最簡(jiǎn)單的使用方式就是運(yùn)行命令:

npm install -g yarnpkg

yarn

在你的開發(fā)流程中 yarn?CLI 取代了?npm?, 要么用一個(gè)匹配的命令，要么使用一個(gè)新的、簡(jiǎn)單的命令:

npm install?→?yarn

不帶參數(shù)的情況下，yarn?命令會(huì)讀取你的 package.json 文件，從 npm 庫中抓取所需的壓縮包然后生成 node_modules 文件夾。這跟你運(yùn)行 npm install 是一樣的。

我們移除了 npm install? 的隱形依賴并拆分了命令。執(zhí)行 yarn 后面加上? 與npm install --save? 的是一樣的。

我們?cè)S多人聚集到一起，共同搭建了 Yarn 來解決常見的問題。我們希望 Yarn 可以真正成為一個(gè)開源項(xiàng)目，方便每個(gè)人使用。Yarn 現(xiàn)在已經(jīng)放到 github?上了。我們也歡迎 Node 社區(qū)的伙伴們使用 Yarn，分享idea，撰寫文檔，我們互相支持，讓更多人來關(guān)注它、使用它！我們相信 Yarn 已經(jīng)有個(gè)很好的開端了，未來在大家的幫助下，一定會(huì)變得更好！