什么是 Monorepo?

隨著前端工程日益復(fù)雜，某些業(yè)務(wù)或者工具庫(kù)通常涉及到很多個(gè)倉(cāng)庫(kù)，那么時(shí)間一長(zhǎng)，多個(gè)倉(cāng)庫(kù)開(kāi)發(fā)弊端日益顯露，由此出現(xiàn)了一種新的項(xiàng)目管理方式——Monorepo。本文主要以 Monorepo 的概念、MultiRepo的弊端、Monorepo 的收益以及Monorepo 的落地這幾個(gè)角度來(lái)認(rèn)識(shí)和學(xué)習(xí)一下 Monorepo，文末會(huì)有思考題，歡迎大家來(lái)踴躍討論。

Monorepo 其實(shí)不是一個(gè)新的概念，在軟件工程領(lǐng)域，它已經(jīng)有著十多年的歷史了。概念上很好理解，就是把多個(gè)項(xiàng)目放在一個(gè)倉(cāng)庫(kù)里面，相對(duì)立的是傳統(tǒng)的 MultiRepo 模式，即每個(gè)項(xiàng)目對(duì)應(yīng)一個(gè)單獨(dú)的倉(cāng)庫(kù)來(lái)分散管理。

現(xiàn)代的前端工程已經(jīng)越來(lái)越離不開(kāi) Monorepo 了，無(wú)論是業(yè)務(wù)代碼還是工具庫(kù)，越來(lái)越多的項(xiàng)目已經(jīng)采用 Monorepo 的方式來(lái)進(jìn)行開(kāi)發(fā)。Google 寧愿把所有的代碼都放在一個(gè) Monorepo 工程下面，Vue 3、Yarn、Npm7 等等知名開(kāi)源項(xiàng)目的源碼也是采用 Monorepo 的方式來(lái)進(jìn)行管理的。

一般 Monorepo 的目錄如下所示，在 packages 存放多個(gè)子項(xiàng)目，并且每個(gè)子項(xiàng)目都有自己的package.json:

├── packages
|   ├── pkg1
|   |   ├── package.json
|   ├── pkg2
|   |   ├── package.json
├── package.json

那 Monorepo 究竟有什么魔力，讓大家如此推崇，落地如此之廣呢？

MultiRepo 之痛

要想知道 Monorepo 的優(yōu)勢(shì)，首先得弄清楚之前的開(kāi)發(fā)方式有什么痛點(diǎn)。

之前傳統(tǒng)的方式MultiRepo當(dāng)中，每個(gè)項(xiàng)目都對(duì)應(yīng)單獨(dú)的一個(gè)代碼倉(cāng)庫(kù)。我之前也是用這種方式開(kāi)發(fā)的，是真真切切地感受到了這種方式帶來(lái)的諸多弊端?，F(xiàn)在就和大家一一分享一下。

1.代碼復(fù)用

在維護(hù)多個(gè)項(xiàng)目的時(shí)候，有一些邏輯很有可能會(huì)被多次用到，比如一些基礎(chǔ)的組件、工具函數(shù)，或者一些配置，你可能會(huì)想: 要不把代碼直接 copy 過(guò)來(lái)，多省事兒！但有個(gè)問(wèn)題是，如果這些代碼出現(xiàn) bug、或者需要做一些調(diào)整的時(shí)候，就得修改多份，維護(hù)成本越來(lái)越高。

那如何來(lái)解決這個(gè)問(wèn)題呢？比較好的方式是將公共的邏輯代碼抽取出來(lái)，作為一個(gè) npm 包進(jìn)行發(fā)布，一旦需要改動(dòng)，只需要改動(dòng)一份代碼，然后 publish 就行了。

但這真的就完美解決了么？我舉個(gè)例子，比如你引入了 1.1.0 版本的 A 包，某個(gè)工具函數(shù)出現(xiàn)問(wèn)題了，你需要做這些事情：

• 去修改一個(gè)工具函數(shù)的代碼
• 發(fā)布1.1.1版本的新包
• 項(xiàng)目中安裝新版本的 A。

可能只是改了一行代碼，需要走這么多流程。然而開(kāi)發(fā)階段是很難保證不出 bug 的，如果有個(gè)按鈕需要改個(gè)樣式，又需要把上面的流程重新走一遍......停下來(lái)想想，這些重復(fù)的步驟真的是必須的嗎？我們只是想復(fù)用一下代碼，為什么每次修改代碼都這么復(fù)雜？

上述的問(wèn)題其實(shí)是 MultiRepo普遍存在的問(wèn)題，因?yàn)椴煌膫}(cāng)庫(kù)工作區(qū)的割裂，導(dǎo)致復(fù)用代碼的成本很高，開(kāi)發(fā)調(diào)試的流程繁瑣，甚至在基礎(chǔ)庫(kù)頻繁改動(dòng)的情況下讓人感到很抓狂，體驗(yàn)很差。

2.版本管理

在 MultiRepo 的開(kāi)發(fā)方式下，依賴包的版本管理有時(shí)候是一個(gè)特別玄學(xué)的問(wèn)題。比如說(shuō)剛開(kāi)始一個(gè)工具包版本是 v1.0.0，有諸多項(xiàng)目都依賴于這個(gè)工具包，但在某個(gè)時(shí)刻，這個(gè)工具包發(fā)了一個(gè) break change 版本，和原來(lái)版本的 API 完全不兼容。而事實(shí)上有些項(xiàng)目并沒(méi)有升級(jí)這個(gè)依賴，導(dǎo)致一些莫名的報(bào)錯(cuò)。

當(dāng)項(xiàng)目多了之后，很容易出現(xiàn)這種依賴更新不及時(shí)的情況。這又是一個(gè)痛點(diǎn)。

3.項(xiàng)目基建

由于在 MultiRepo 當(dāng)中，各個(gè)項(xiàng)目的工作流是割裂的，因此每個(gè)項(xiàng)目需要單獨(dú)配置開(kāi)發(fā)環(huán)境、配置 CI 流程、配置部署發(fā)布流程等等，甚至每個(gè)項(xiàng)目都有自己?jiǎn)为?dú)的一套腳手架工具。

其實(shí)，很容易發(fā)現(xiàn)這些項(xiàng)目里的很多基建的邏輯都是重復(fù)的，如果是 10 個(gè)項(xiàng)目，就需要維護(hù) 10 份基建的流程，邏輯重復(fù)不說(shuō)，各個(gè)項(xiàng)目間存在構(gòu)建、部署和發(fā)布的規(guī)范不能統(tǒng)一的情況，這樣維護(hù)起來(lái)就更加麻煩了。

Monorepo 的收益

說(shuō)清楚 MultiRepo 的痛點(diǎn)之后，相信你也大概能理解為什么要誕生Monorepo這個(gè)技術(shù)了?，F(xiàn)在就來(lái)細(xì)致地分析一下Monorepo到底給現(xiàn)代的前端工程帶來(lái)了哪些收益。

首先是工作流的一致性，由于所有的項(xiàng)目放在一個(gè)倉(cāng)庫(kù)當(dāng)中，復(fù)用起來(lái)非常方便，如果有依賴的代碼變動(dòng)，那么用到這個(gè)依賴的項(xiàng)目當(dāng)中會(huì)立馬感知到。并且所有的項(xiàng)目都是使用最新的代碼，不會(huì)產(chǎn)生其它項(xiàng)目版本更新不及時(shí)的情況。

其次是項(xiàng)目基建成本的降低，所有項(xiàng)目復(fù)用一套標(biāo)準(zhǔn)的工具和規(guī)范，無(wú)需切換開(kāi)發(fā)環(huán)境，如果有新的項(xiàng)目接入，也可以直接復(fù)用已有的基建流程，比如 CI 流程、構(gòu)建和發(fā)布流程。這樣只需要很少的人來(lái)維護(hù)所有項(xiàng)目的基建，維護(hù)成本也大大減低。

再者，團(tuán)隊(duì)協(xié)作也更加容易，一方面大家都在一個(gè)倉(cāng)庫(kù)開(kāi)發(fā)，能夠方便地共享和復(fù)用代碼，方便檢索項(xiàng)目源碼，另一方面，git commit 的歷史記錄也支持以功能為單位進(jìn)行提交，之前對(duì)于某個(gè)功能的提交，需要改好幾個(gè)倉(cāng)庫(kù)，提交多個(gè) commit，現(xiàn)在只需要提交一次，簡(jiǎn)化了 commit 記錄，方便協(xié)作。

Monorepo 的落地

如果你還從來(lái)沒(méi)接觸過(guò) Monorepo 的開(kāi)發(fā)，到這可能你會(huì)疑惑了: 剛剛說(shuō)了這么多 Monorepo 的好處，可是我還是不知道怎么用?。∈侵苯影阉械拇a全部搬到一個(gè)倉(cāng)庫(kù)就可以了嗎?

當(dāng)然不是，在實(shí)際場(chǎng)景來(lái)落地 Monorepo，需要一套完整的工程體系來(lái)進(jìn)行支撐，因?yàn)榛?Monorepo 的項(xiàng)目管理，絕不是僅僅代碼放到一起就可以的，還需要考慮項(xiàng)目間依賴分析、依賴安裝、構(gòu)建流程、測(cè)試流程、CI 及發(fā)布流程等諸多工程環(huán)節(jié)，同時(shí)還要考慮項(xiàng)目規(guī)模到達(dá)一定程度后的性能問(wèn)題，比如項(xiàng)目構(gòu)建/測(cè)試時(shí)間過(guò)長(zhǎng)需要進(jìn)行增量構(gòu)建/測(cè)試、按需執(zhí)行 CI等等，在實(shí)現(xiàn)全面工程化能力的同時(shí)，也需要兼顧到性能問(wèn)題。

因此，要想從零開(kāi)始定制一套完善的 Monorepo 的工程化工具，是一件難度很高的事情。不過(guò)社區(qū)已經(jīng)提供了一些比較成熟的方案，我們可以拿來(lái)進(jìn)行定制，或者對(duì)于一些上層的方案直接拿來(lái)使用。

其中比較底層的方案比如 lerna，封裝了 Monorepo 中的依賴安裝、腳本批量執(zhí)行等等基本的功能，但沒(méi)有一套構(gòu)建、測(cè)試、部署的工具鏈，整體 Monorepo 功能比較弱，但要用到業(yè)務(wù)項(xiàng)目當(dāng)中，往往需要基于它進(jìn)行頂層能力的封裝，提供全面工程能力的支撐。

當(dāng)然也有一些集成的 Monorepo 方案，比如rushstack，提供從初始化、開(kāi)發(fā)、構(gòu)建、測(cè)試到部署的全流程能力，有一套比較完整的 Monorepo 基礎(chǔ)設(shè)施，適合直接拿來(lái)進(jìn)行業(yè)務(wù)項(xiàng)目的開(kāi)發(fā)。不過(guò)由于這些頂層方案內(nèi)部各種流程和工具鏈都已經(jīng)非常完善了，如果要基于這些方案來(lái)定制，適配和維護(hù)的成本過(guò)高，基本是不可行的。

總結(jié)

總而言之，Monorepo 的開(kāi)發(fā)模式就是將各自獨(dú)立的項(xiàng)目，變成一個(gè)統(tǒng)一的工程整體，解決 MultiRepo 下出現(xiàn)的各種痛點(diǎn)，提升研發(fā)效率和工程質(zhì)量。那最后我還有有一個(gè)問(wèn)題，采用 Monorepo 解決了之前的痛點(diǎn)之后，產(chǎn)生了哪些新的問(wèn)題呢？這些問(wèn)題可以解決嗎？更多關(guān)于Monorepo前端項(xiàng)目管理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論