用 Nx Monorepo 解決多品牌版本漂移

情境

Gorilla 當時已經有多組品牌產品，也累積了不少 Shared Packages。

架構本身有共用概念，但 Repository 與 Package Version 仍然分散管理。

實際開發時常遇到：

• 某個品牌沒有升到最新 Package
• 開發者本機使用的版本不同
• Shared Package 已經修正問題，但部分產品仍停留在舊版
• 發生 Bug 時，需要先確認到底是哪個版本造成差異

問題不是沒有共用，而是：

共用能力雖然只有一套，但 Consumers 使用的卻不一定是同一個版本。

當品牌與 Packages 越來越多，版本漂移本身逐漸成為維護成本。

我的判斷與做法

我開始評估把品牌 Applications 與 Shared Packages 放進同一個 Workspace 管理，最後導入 Nx Monorepo。

選擇 Nx 除了 Dependency Graph、Affected 等能力之外，我也考量團隊導入成本，因此利用 Nx Console，讓不熟悉 CLI 的工程師仍可以透過 GUI 操作常見工作。

同一時期公司也由 GitLab 遷移到 GitHub，我與同事一起重新建立適用於 Monorepo 的 GitHub Actions：

• Build
• Lint
• Test
• Affected Modules
• Package Release

讓版本管理、Dependency 與 CI/CD 可以一起收斂。

形成的結果

原本分散在不同 Repository 的品牌產品與 Packages，可以在同一個 Workspace 中理解彼此的依賴關係。

Shared Package 修改後，哪些 Application 受到影響變得更清楚，也不再需要先猜某個品牌究竟使用哪個版本。

留下的思考

這是我第一次真正理解 Monorepo 的價值並不只是：

把很多 Repository 搬到一起。

真正重要的是讓原本彼此相關的程式碼、版本與 Dependency Graph，被放回同一個可以被管理的系統裡。

如果產品本來就在共享能力，它們的工程結構也應該能看見這層關係。