使用rush.js管理monorepo

本文首發於公衆號：符合預期的CoyPan

寫在前面

2019年9月21號，我參加了第五屆FEDAY。在會上，聽了王澤老師的分享，我第一次接觸到了monorepo這個概念。本文是結合王澤老師的分享，本身進行必定實踐後的總結。

本文中的圖片，均來自我在團隊內部分享時的PPT截圖

Monorepo

一種項目管理方式：一個git倉庫下管理多個項目，適用於大型團隊，框架開發，庫開發等。

線上項目現狀

一看到這個概念，我立馬想起了本身所在團隊的一個repo，目錄大概長成下面這樣：

這種把全部的項目都放到一個repo下面的好處是：

1. 統一技術棧
   • 下降團隊成員之間的backup成本
2. 提高效率
   • 每個人均可以改動任意部分的代碼，改動效果實時呈現，調試方便
   • 能夠在業務開發中，靈活地將代碼抽出做爲公共模塊
   • 省去了在多個repo狀況下，給團隊新成員開通repo權限的時間

大概的repo組織結構是下面這樣的：

上圖這種repo組織方式對團隊如今的業務開發來講，徹底足夠了，由於每個頁面都還算簡單。可是若是要開發一個大型複雜項目，會有問題嘛？

大型複雜項目怎麼辦

上圖的狀況在平時的開發中很常見，B項目或許根本就沒有時間、人力來回歸測試，可是A項目很着急上線，也顧不上這麼多。若是業務複雜度小，那這種狀況通常不是問題。若是是大型複雜的項目，怎麼辦呢？項目A從新複製一個基礎庫a來修改嗎？

解決辦法就是：版本管理。對組件進行版本管理，託管在公司內部的組件庫裏面。

到底什麼是monorepo

微軟的定義以下：

再來看看著名的babel和React:

我本身的總結以下：

rush.js

微軟出品的，一個專門爲monorepo打造的項目管理工具。rushjs.io。

rush.js解決了兩個重要的問題：phantom dependencies 和 doppelgangers。咱們先來看看這兩個問題。

phantom dependencies

沒有在package.json裏指定安裝，卻能夠在項目中被引用的依賴。

在npm3.0之後，是能夠的。這是由於：npm原有的樹形結構，形成了依賴冗餘和路徑過深。npm3後開始扁平化，把原來不一樣級的依賴變成了同級依賴。這樣咱們在項目中就能直接引用到了。

phantom dependencies的問題：

• 依賴版本混亂
• 依賴丟失

常規解決思路：制定代碼規範；使用代碼檢查工具來避免這種狀況發生。可是......

doppelgangers

同一個依賴被屢次安裝，致使項目臃腫，打包變慢。

rush.js的Symlink機制

Rush會將項目依賴所有都安裝在repo根目錄的common/temp下，而後提供symlink到各個項目中去引用。本來的項目中，依然會保持原有的node_modules結構。

看一個例子：

Rush保證只會在項目的node_modules中保留package.json中聲明過的依賴的Symlink。這樣，天然解決了phantom dependencies

rush會將全部的依賴都安裝在一個地方，對於不一樣版本的同一個依賴，rush會同時安裝全部的依賴版本，而且提供symlink供項目使用，這樣，天然就解決了doppelgangers。

另外，rush會對依賴的版本（SemVer）進行智能判斷，防止重複安裝依賴包。例如，兩個項目同時依賴了一個第三方庫，第一個項目依賴的是：^1.2.0，另外一個依賴的版本號是：1.5.0。rush安裝依賴時，只會安裝1.5.0。

rush.js的簡單使用介紹

下面簡單介紹一下rush.js的使用。

• rush.json

  

• rush build

  

• rush update

  

• rush change

  

• rush publish

  

寫在後面

本文介紹了monorepo，同時對rush.js進行了簡單的探索。monorepo已經有不少的案例了，好比上面提到的babel,react。monorepo的管理也有很成熟的工具了，如著名的lerna。通過一些小小的研究，我對rush.js的印象是：很規範，可是對於團隊來講，上手成本真的不小。

目前我所在團隊負責的業務，並無適合monorepo的場景，全部也沒有對rush.js,lerna等工具進行更深刻的瞭解與對比。但願有經驗的大佬可以深刻分享一下本身的體會。

參考資料：

rushjs.io/

www.zhihu.com/question/33…