你很常聽到 monorepo，但為什麼要用 monorepo?

身為前端工程師，或許你很常聽到別人說用 monorepo 的好處很多。以前端來說，Lerna、Nx，以及 Turborepo，都是社群許多人會用的選擇。多數大公司的前端基礎建設團隊 (frontend infra team) 都會有專職在負責 monorepo。但是什麼是 monorepo? 為什麼要用 monorepo? 好處是什麼? 在這一期我們將與大家聊這個主題。

所謂的 monorepo，是由 mono 跟 repo 組成的，mono 在英文的字首有單一的意思，而 repo 就是 repository 也就是程式碼庫，所以組合起來 monorepo，就是指用單一程式碼庫，來存放不同項目的程式碼管理模式。相對來說，假如把不同項目，放在不同的程式碼庫，會被稱為 polyrepo。

在了解完 monorepo 的基本定義，下個問題要問的是，它解決了 polyrepo 的什麼問題? Turborepo 官方文件的說明範例，非常淺顯易懂，這邊摘要給大家

在 polyrepo 的模式下

你有三個不同的程式碼庫：一個是應用程式 (app)，一個是文件 (docs)，還有一個是共用的工具 (shared-utils)。因為想要共用 shared-utils，我們需要把它發布到 npm 上，讓 app 和 docs 安裝並都依賴 shared-utils。假設 shared-utils 有個 bug，這個 bug 對 app 和 docs 都造成問題。當你修完這個 bug 之後，需要這樣做：

• 在 shared-utils 提交一個修復 bug 的更改
• 在 shared-utils 內執行發布任務，將新版本發布到 npm
• 在 app 更新 shared-utils 的版本
• 在 docs 中也做同樣的版本更新
• 然後 app 和 docs 才能準備部署

如果有越來越多的應用程式依賴 shared-utils，這個流程就會變得更長更繁瑣。

假如用 monorepo

shared-utils 與 app 和 docs 在同一個程式碼庫中。這使得過程變得非常簡單：

• 在 shared-utils 中提交一個修復 bug 的更新
• app 和 docs 就準備好可以部署

用 monorepo 代表不需要進行版本控制，因為 app 和 docs 不依賴 npm 中的 shared-utils 版本，而是依賴 monorepo 中的版本。

從上面得例子，可以看到 monorepo 顯而易見的好處是，共享程式碼變很簡單，同時能做到原子化更改，在更改共用的程式碼時，同時可以在同一個更新中，修改依賴該程式碼的應用程式，這樣做可以避免在多個程式碼庫之間協調更新的麻煩。

此外，因為都在同一個程式碼庫、依賴單一的版本，可以減少應用程式之間的不一致性。即使是不經常更新的應用程式，也能跟最新版本。這對開發人員的負擔，會明顯小很多。

為什麼不把所有程式碼都放在一個程式碼庫

讀到這邊你可能會問，那為什麼我們不把所有程式碼都放在一個程式碼庫，只有一個超大的項目，不用分項目，這樣也可以做到共享，為什麼還要 monorepo 這種種架構呢?

單純把程式碼放在一起(code collocation) 確實可以輕易共享，且做到依賴單一版本並，但也有顯而易見的問題，包含執行不必要的測試，在單純的程式碼並置中，即使更改和某些項目無關，整個程式碼庫的所有測試都會被執行。這就好像為了一個小變動，讓所有不相關的專案也受到影響。

此外，這也會讓程式碼相對沒邊界，如果一個團隊的開發者修改了另一個團隊的程式碼，可能會引入錯誤或不一致。因此，我們需要一個架構，讓我們享有程式碼並置 (code collocation) 好處，同時避免其壞處，monorepo 即是能做到這樣的解決方案。

以上是針對 monorepo 的介紹，以及聊了為什麼要 monerepo。基本上現在多數的科技大廠都是走 monorepo 的模式，假如你還沒用過，推薦可以試試上面有提到的 Lerna、Nx 或 Monorepo。