Yarn更快更可靠的CI建立工具

你可能聽說過 Yarn ，它劍指蒼穹，要做成一個更快、更可靠的 npm 客戶端。能夠更快的在本地安裝擴充套件包的確很棒，但是為了真正能夠使用 Yarn 到淋漓盡致，你最好在持續繼整合務器上使用它。

當配合一臺持續整合伺服器使用時，Yarn 能夠減少因為各式各樣的安裝包的解析方式不同導致的隨機 CI 錯誤。

由於安裝緩慢和 CI 產生的隨機錯誤會降低整個團隊的開發效率，它們將會成倍地給你的團隊拖後腿。隨機錯誤的出現甚至比安裝緩慢更令人沮喪，因為一旦出錯，你必須要確定是程式出現了 BUG 還是擴充套件包的問題。知之非難，行之不易。

Yarn 來拯救你了！

Yarn 誤區

• 一種新的 npm 資源管理器

Yarn 並不是 npm 的包資源管理器的替代，它也並非是一款有競爭力的擴充套件包生態管理庫，所以它不會重蹈 Bower 慘敗的覆轍。

Yarn 是一款與 npm 包管理協同工作的軟體。

Yarn 正解

• 安裝更快。
• 確定的依賴管理 — 通過 yarn.lock，你能夠每次都獲取到相同安裝位置相同版本的包檔案。

轉戰 Yarn

Yarn 剛剛釋出的時候，我馬上意識到它可能會非常有價值，但是我仍然按兵不動，想看看它是否真的實現了當時吹下的牛逼。

後來越來越多的人說 Yarn 很好用，我才決定要在一款應用中使用它。

安裝 Yarn

Yarn 團隊建議像安裝原生應用那樣安裝 Yarn，而我建議你完全可以不看他們的安裝文件。

Yarn 沒有 Mac 的原生安裝包，所以他們推薦在 Mac 上使用 Homebrew。除非你已經用 Homebrew 安裝了 Node（其實我並不推薦這樣做 — 使用 nvm 能減少很多麻煩，也能自由地切換版本），否則不要用 Homebrew 來安裝 Yarn.

Homebrew 安裝的同時也會安裝 Node，它會將全域性的 node 和 npm 命令新增到 Homebrew 路徑中，並且會破壞你原本的 Node 的安裝。

另外，由於 Homebrew 路徑的依賴管理問題，如果你升級 macOS 到最新版，它將會打亂 usr/local 的許可權從而破壞 Homebrew ，因此你還需要整理這團亂麻。

幸虧還有更好的選擇：

npm install -g yarn

好處：當你搭建 CI 伺服器的時候，你同樣需要 npm ，所以你可以使用相同的方法安裝 yarn 在任何你需要的地方。

很諷刺吧，是的：我確實建議你安裝一個 JavaScript 包管理工具來安裝新的 JavaScript 包管理工具。我確信，這也是 Yarn 團隊建議在 Mac 上使用 Homebrew 安裝的真正原因，是為了避免這種稍稍有點尷尬的諷刺的事情。但是相信我：

npm 對於有經驗的 JavaScript 開發者來說，這是最簡單最好的安裝 Yarn 的方式。

Yarn 團隊會告訴你 OS 原生包依賴管理工具才是最好的方式，因為它會記錄你所有的包依賴關係。我瞭解這種關係，但事實上這隻在 Linux 系統下才支援。況且 Homebrew 並不是 macOS 原生的包依賴管理工具，它並不會也不應該管理你所有的應用依賴。

Yarn 最主要的依賴是 Node，並且 Homebrew 並不是安裝 Node 的最好的方式。既然如此，我們為什麼還要用 Homebrew 去管理 Yarn 的依賴關係呢？

Windows 下那又是別有洞天了，由於我並不瞭解，所以我暫不評論 Windows 下的安裝如何。

你知道什麼包管理軟體能夠在Mac、Windows和Linux下用法相同卻沒有跨平臺的煩惱呢？ npm。

使用 Yarn

有一些你需要識記的命令，簡而言之：

新增依賴

yarn add

新增開發依賴

yarn add --dev

移除依賴

yarn remove

安裝

yarn （安裝是預設行為）

以上是你大部分時候會用到的。

鎖定檔案

Yarn 非常神奇地用 yarn.lock 檔案解決了確定的依賴關係，它應該是一種更加可靠的 npm shrinkwrap 的形式。關鍵的區別就是 npm 的安裝演算法並不是確定的，甚至是壓縮演算法，而 Yarn 的演算法是確定的。這意味著使用同一個鎖定檔案，你在這臺機器上的安裝將會和在另一臺機器上的安裝完全相同。

不要在 git 中忽略 yran.lock ，它的存在就是為了保證確定的依賴關係，從而避免 “works on my machine” 的錯誤。

為了讓鎖定檔案能夠大顯神通，你必須在 git 中 check 它。

搭建持續整合服務

正如我在安裝階段所提到的那這樣，你可以用 npm install -g yarn 方式安裝 yarn ，這種方式能夠在大多數 CI 伺服器上執行。以下是 Travis-CI users 的一個 .travis.yml例子：

language: node_js
node_js:
  - "6"
env:
  - CXX=g++-4.8
addons:
  apt:
    sources:
      - ubuntu-toolchain-r-test
    packages:
      - g++-4.8
before_install:
  - npm install -g yarn --cache-min 999999999
install:
  - yarn

實際上 Yarn 到底如何工作？

如果你非常好奇 yarn 安裝到底有多快，以下是我在應用中測試安裝 from-scratch 的資料：

使用 npm:

$ time npm install
0m30.193s

使用 Yarn:

$ time yarn
0m44.835s

哦！

Yarn 的主要的賣點就在於它要比 npm 更快，但是在我的專案實測中，它實際上在從 scratch 安裝依賴的時候更慢了。

那麼新增新的依賴呢？

使用 npm:

$ time npm install lodash
0m6.204s

使用 Yarn:

$ time yarn add lodash
0m2.948s

OK，這才像點樣子。我一直還在擔心 from-scratch 的安裝時間，但是現在，利用 yarn 新增擴充套件包大概比 npm 快了兩倍。

顯然，from-scrath 的安裝仍然有很大的提升空間（這決定了你的 CI 的安裝速度），但是我已經很滿意了。

且對它持半信半疑的態度，因為這些結果可能會因系統、版本等因素而有不同。

小結

迄今為止，我對 Yarn 的體驗大部分情況下都很好。

我僅僅是剛開始在產品中測試，所以我不能很自信地對其穩定性論及一二，但是我抱以樂觀的心態。

如果 Yarn 能夠證明如萬眾期待的那樣，它將會節省你的團隊非常多的時間。但是到目前為止，我得到的結果也良莠不齊。

你是不是也應該使用 Yarn ？

讓我現在很絕對地說是有點太早了，但是我將會樂觀地給予它鼓勵性的肯定。我非常支援 Yarn 團隊能夠在後續的時間裡解決問題並不斷做出改進。