[譯] 將項目遷移到 Yarn 而後又遷回 npm

• 原文地址：To Yarn and Back (to npm) Again
• 原文做者：Spencer Brown
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：DM.Zhong
• 校對者：Starriers，wyh888

去年，咱們決定將全部 JavaScript 項目從 npm 遷移到 Yarn。

之因此這樣作，有如下兩個主要緣由：

• yarn install 比 npm install 快 20 倍。npm install 在咱們的一些大型項目中每每須要消耗 20 分鐘以上。
• Yarn 的依賴鎖定比 npm 的更加可靠。

查看去年的一篇博客（連接在上方給出了）能夠了解更多。

使用 Yarn 的 13 個月

Yarn 解決了咱們在使用 npm 時所遇到的一些煩人的問題，可是它自身也帶來了許多的問題：

• Yarn 出現了很是很差的迴歸，這讓咱們不太敢升級它。
• Yarn 常常會在你運行 add，remove 或者 update 的時候生成無效的 yarn.lock 文件。這就使得開發者須要作一些冗餘的工做來 remove 和 add 這些有衝突的包，直到 Yarn 找出解決方案以使得 yarn check 可以經過，才能改善這一現象。
• 不少時候，由於 Yarn 進行了優化,因此當開發人員在拉取項目的最新變化後運行 yarn 時，他們的 yarn.lock 文件會變的很「髒」，。爲了解決這個問題，須要開發人員推送與他們工做無關的更改。Yarn 須要在使用命令 yarn lock 更新時當即優化，而不是在下一次使用 yarn 命令時。
• yarn publish 不是很可靠（存在問題？）（tracked issues #1, tracked issue #2），這意味着咱們不得不使用 npm publish 來發布包。這使咱們很容易忘記在這種特殊場景下須要使用 npm，而且意外地使用 Yarn 發佈包致使發佈的包沒法安裝。

不幸的是，在咱們使用 Yarn 的 13 個月裏，這些工做流很混亂的問題一個都沒有被修復。

在經歷了特別痛苦的幾個星期（常常開 15 分鐘的 Yarn 問題解決會議）後，咱們決定迴歸到 npm。

npm 6

在咱們使用 Yarn 的這段時間裏，npm 作出了重大的改善，以期擁有 Yarn 的速度及其依賴鎖定的可靠性 —— 這些問題曾使得咱們轉向了 Yarn。就像 Yarn 裏面的那些煩人的問題同樣，咱們沒法離開這些好處，所以咱們首先須要驗證一下 npm 是否解決了原來的那些問題。

咱們決定嘗試一下當前可以獲取到的最新版本的 npm，npm@​6.0.0，由於咱們想要利用盡量多的速度改善和 bug 修復。據傳 npm​@6.0.0 是一個相對較小的重大更新，所以咱們認爲使用它不會冒很大的風險。難以想象的是，npm​@5.8.1 使咱們在 6.0.0 發佈以前測試過的版本，在咱們許多開發工程師的機器上（OS X Sierra/High Sierra，node​@v8.9.3）安裝依賴失敗了，出現了許多錯誤（好比 cb() never called!）。

速度

咱們很高興地發現，在每一個包管理器試用五個案例後，npm的平均成績與 Yarn 至關：

• Yarn：$ rm -rf node_modules && time yarn：126s
• npm：$ rm -rf node_modules && time npm i：132s

在正確的方向上邁出了正確的一步。咱們的試驗還會繼續 :)。

Locking

npm 在 npm@​5.0.0 引入了 package-lock.json 等價於 Yarn 中的 yarn.lock。npm shrinkwrap 仍然能夠被用於建立 npm-shrinkwrap.json 文件，可是根據 npm 文檔的描述，這些文件的使用場景有了一些不一樣：

推薦的 npm-shrinkwrap.json 使用場景是經過發佈過程在註冊表中部署的應用程序：例如，用做全局安裝或 devDependencies 的守護程序和命令行工具。對於庫做者發佈這個文件很是不鼓勵，由於這會阻止最終用戶控制傳遞依賴關係更新。

另外一方面，package-lock.json 文件不跟隨包一塊兒發佈。這至關於 Yarn 如何不尊重依賴關係的 yarn.lock 文件 —— 父項目管理本身的依賴關係和子依賴關係（但要注意的是，若是庫的確在不該該的時候發佈 npm-shrinkwrap.json 文件,那麼您將不得不使用它們的依賴性）。

Locking 驗證

npm 沒有與 Yarn 的 yarn check 相對應的功能，但 yarn check 看起來像一些人（如 Airbnb）使用 npm ls> / dev / null 來檢查安裝錯誤，如缺乏軟件包。

不幸的是，檢查將 peer 依賴警告視爲錯誤，這使得咱們沒法使用它，由於咱們常常經過 CDN 實現 peer 依賴關係。

npm 最近引入了 npm ci，很幸運它提供了一些驗證功能。npm ci 確保了 package-lock.json 和 package.json 在同一驗證形式下是同步的。它一樣提供了一些其它好處 —— 查看文檔瞭解更多。

以前在使用 npm 時，咱們從未意識到 install 的不一致性（彷佛只有 Yarn 有這些問題 :)），所以咱們認爲只使用 npm ci 是安全的。

使用 Yarn 的煩惱

除了追上 Yarn 的速度和擁有 Yarn 依賴關係鎖定的保證以外，npm 彷佛沒有任何使用 Yarn 時困擾咱們的問題！

Check, check, check

npm​@6.0.0 爲咱們檢查了全部的盒子，因此咱們決定之後繼續使用它！

在對咱們的一個服務進行爲期三週的試驗成功後，咱們將剩餘的其它服務和項目也遷移到了 npm！

建議

deyarn

咱們已經發布了一個叫作 deyarn 的開源模塊，它能夠幫助你將項目從 Yarn 遷移到 npm。

經過 engines 強制使用 npm

咱們推薦使用 engines 選項，它可讓你避免在應該使用 npm 的時候卻意外地使用了 Yarn 了。

咱們已經添加了一個配置以下：

{
    "engines": {
    "yarn": "NO LONGER USED - Please use npm"
    }
}
複製代碼

對於咱們內部項目的全部的 package.json 而言。deyarn（連接在上方給出）會幫你管理 :)。

試試它！

咱們測試過這個工做流可以知足咱們的需求，而且咱們也推薦你使用它。若是你須要一個極致快速的包管理器，而後你會發現 Yarn 仍然是最佳之選。可是若是你須要一個創建起來比較簡單的包管理器，咱們發現 npm 6 在速度與可靠性上保持了很好的平衡。

想要幫助咱們使用 npm 創建將來的社區嗎？

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。