隨著前端工程日益複雜，某些業務或者工具庫通常涉及到很多個倉庫，那麼時間一長，多個倉庫開發弊端日益顯露，由此出現了一種新的專案管理方式——Monorepo。本文主要以 Monorepo 的概念、MultiRepo 的弊端、Monorepo 的收益以及 Monorepo 的落地這幾個角度來認識和學習一下 Monorepo，文末會有思考題，歡迎大家來踴躍討論。
什麼是 Monorepo?
Monorepo 其實不是一個新的概念，在軟體工程領域，它已經有著十多年的歷史了。概念上很好理解，就是把多個專案放在一個倉庫裡面，相對立的是傳統的 MultiRepo 模式，即每個專案對應一個單獨的倉庫來分散管理。
現代的前端工程已經越來越離不開 Monorepo 了，無論是業務程式碼還是工具庫，越來越多的專案已經採用 Monorepo 的方式來進行開發。Google 寧願把所有的程式碼都放在一個 Monorepo 工程下面，Vue 3、Yarn、Npm7 等等知名開源專案的原始碼也是採用 Monorepo 的方式來進行管理的。
一般 Monorepo 的目錄如下所示，在 packages 存放多個子專案，並且每個子專案都有自己的package.json:
├── packages
| ├── pkg1
| | ├── package.json
| ├── pkg2
| | ├── package.json
├── package.json
那 Monorepo 究竟有什麼魔力，讓大家如此推崇，落地如此之廣呢？
MultiRepo 之痛
要想知道 Monorepo 的優勢，首先得弄清楚之前的開發方式有什麼痛點。
之前傳統的方式 MultiRepo 當中，每個專案都對應單獨的一個程式碼倉庫。我之前也是用這種方式開發的，是真真切切地感受到了這種方式帶來的諸多弊端。現在就和大家一一分享一下。
程式碼複用
在維護多個專案的時候，有一些邏輯很有可能會被多次用到，比如一些基礎的元件、工具函式，或者一些配置，你可能會想: 要不把程式碼直接 copy 過來，多省事兒！但有個問題是，如果這些程式碼出現 bug、或者需要做一些調整的時候，就得修改多份，維護成本越來越高。
那如何來解決這個問題呢？比較好的方式是將公共的邏輯程式碼抽取出來，作為一個 npm 包進行釋出，一旦需要改動，只需要改動一份程式碼，然後 publish 就行了。
但這真的就完美解決了麼？我舉個例子，比如你引入了 1.1.0 版本的 A 包，某個工具函式出現問題了，你需要做這些事情：
- 去修改一個工具函式的程式碼
- 釋出
1.1.1版本的新包 - 專案中安裝新版本的
A。
可能只是改了一行程式碼，需要走這麼多流程。然而開發階段是很難保證不出 bug 的，如果有個按鈕需要改個樣式，又需要把上面的流程重新走一遍......停下來想想，這些重複的步驟真的是必須的嗎？我們只是想複用一下程式碼，為什麼每次修改程式碼都這麼複雜？
上述的問題其實是 MultiRepo 普遍存在的問題，因為不同的倉庫工作區的割裂，導致複用程式碼的成本很高，開發除錯的流程繁瑣，甚至在基礎庫頻繁改動的情況下讓人感到很抓狂，體驗很差。
版本管理
在 MultiRepo 的開發方式下，依賴包的版本管理有時候是一個特別玄學的問題。比如說剛開始一個工具包版本是 v1.0.0，有諸多專案都依賴於這個工具包，但在某個時刻，這個工具包發了一個 break change 版本，和原來版本的 API 完全不相容。而事實上有些專案並沒有升級這個依賴，導致一些莫名的報錯。
當專案多了之後，很容易出現這種依賴更新不及時的情況。這又是一個痛點。
專案基建
由於在 MultiRepo 當中，各個專案的工作流是割裂的，因此每個專案需要單獨配置開發環境、配置 CI 流程、配置部署釋出流程等等，甚至每個專案都有自己單獨的一套腳手架工具。
其實，很容易發現這些專案裡的很多基建的邏輯都是重複的，如果是 10 個專案，就需要維護 10 份基建的流程，邏輯重複不說，各個專案間存在構建、部署和釋出的規範不能統一的情況，這樣維護起來就更加麻煩了。
分支管理
在 MultiRepo 的開發方式下，如果組內每個迭代承接業務需求很多，涉及到的工程可能多大五六個，有的業務需求走開發分支，有的業務需求走特性分支，有的需求在轉測或者轉演，有的要熱修等等，這麼多專案的分支管理特別複雜，很容易出現問題。
Monorepo 的收益
說清楚 MultiRepo 的痛點之後，相信你也大概能理解為什麼要誕生 Monorepo 這個技術了。現在就來細緻地分析一下 Monorepo 到底給現代的前端工程帶來了哪些收益。
首先是工作流的一致性，由於所有的專案放在一個倉庫當中，複用起來非常方便，如果有依賴的程式碼變動，那麼用到這個依賴的專案當中會立馬感知到。並且所有的專案都是使用最新的程式碼，不會產生其它專案版本更新不及時的情況。
其次是專案基建成本的降低，所有專案複用一套標準的工具和規範，無需切換開發環境，如果有新的專案接入，也可以直接複用已有的基建流程，比如 CI 流程、構建和釋出流程。這樣只需要很少的人來維護所有專案的基建，維護成本也大大減低。
再者，團隊協作也更加容易，一方面大家都在一個倉庫開發，能夠方便地共享和複用程式碼，方便檢索專案原始碼，另一方面，git commit 的歷史記錄也支援以功能為單位進行提交，之前對於某個功能的提交，需要改好幾個倉庫，提交多個 commit，現在只需要提交一次，簡化了 commit 記錄，方便協作。
Monorepo 的落地
如果你還從來沒接觸過 Monorepo 的開發，到這可能你會疑惑了: 剛剛說了這麼多 Monorepo 的好處，可是我還是不知道怎麼用啊！是直接把所有的程式碼全部搬到一個倉庫就可以了嗎?
當然不是，在實際場景來落地 Monorepo，需要一套完整的工程體系來進行支撐，因為基於 Monorepo 的專案管理，絕不是僅僅程式碼放到一起就可以的，還需要考慮專案間依賴分析、依賴安裝、構建流程、測試流程、CI 及釋出流程等諸多工程環節，同時還要考慮專案規模到達一定程度後的效能問題，比如專案構建/測試時間過長需要進行增量構建/測試、按需執行 CI 等等，在實現全面工程化能力的同時，也需要兼顧到效能問題。
因此，要想從零開始定製一套完善的 Monorepo 的工程化工具，是一件難度很高的事情。不過社群已經提供了一些比較成熟的方案，我們可以拿來進行定製，或者對於一些上層的方案直接拿來使用。
其中比較底層的方案比如 lerna，封裝了 Monorepo 中的依賴安裝、指令碼批量執行等等基本的功能，但沒有一套構建、測試、部署的工具鏈，整體 Monorepo 功能比較弱，但要用到業務專案當中，往往需要基於它進行頂層能力的封裝，提供全面工程能力的支撐。
當然也有一些整合的 Monorepo 方案，比如 nx (官網寫的真心不錯，還有不少視訊教程)、rushstack，提供從初始化、開發、構建、測試到部署的全流程能力，有一套比較完整的 Monorepo 基礎設施，適合直接拿來進行業務專案的開發。不過由於這些頂層方案內部各種流程和工具鏈都已經非常完善了，如果要基於這些方案來定製，適配和維護的成本過高，基本是不可行的。
例項
我在搭建React業務元件庫時使用了lerna管理多包儲存庫，單獨發包，因為工程中只會使用某些業務元件，業務需求的變動只會改動某個業務元件，所以不能像通用元件庫一樣使用全體釋出。
總結
總而言之，Monorepo 的開發模式就是將各自獨立的專案，變成一個統一的工程整體，解決 MultiRepo 下出現的各種痛點，提升研發效率和工程質量。那最後我還有有一個問題，採用 Monorepo 解決了之前的痛點之後，產生了哪些新的問題呢？這些問題可以解決嗎？歡迎大家在留言區一起討論。
參考資料
[1] lerna: https://lerna.js.org/
[2] nx: https://nx.dev/latest/react/g...
[3] rushstack: https://rushstack.io/