最近因為公司的需求，需要開發多個不同版型的專案，其中又有不少部分需要共用。經過一番考慮後，我們決定將原本的專案搬移至 NX，希望藉此提高開發效率、統一管理共用模組，並減少重複撰寫相同功能的時間。
如果你對 NX 有興趣，可以參考官方文件：NX 官方網站。
為什麼選擇 NX？
NX 是一個強大的 Monorepo 工具，適合用來管理多個專案（Apps）與共用函式庫（Libs）。它提供強大的模組管理、靜態分析、快取機制以及自動化工具，讓開發過程更順暢。
在我們的情境中，NX 主要解決了以下幾個痛點：
- 共用模組管理：將重複的邏輯提取到 libs/，方便各專案共用。
- 清晰的專案架構：透過 apps/ 與 libs/ 明確區分專案與函式庫，提升可維護性。
- 更好的開發體驗：NX 提供 CLI 工具與可視化儀表板，方便管理與分析專案。
專案架構
我們目前的 NX 專案架構大致如下：
├── apps/ # 各專案（應用程式）
│ ├── app1/
│ ├── app2/
│ └── …
│
├── libs/ # 共用層
│ ├── domain/ # 邏輯層
│ │ ├── hooks/ # 共用 Hooks
│ │ ├── store/ # 狀態管理
│ ├── api/ # API 整合層
│ ├── interface/ # 介面層
│ │ ├── response/ # 回應型別定義
│ │ └── request/ # 請求型別定義
│ ├── ui/ # UI 元件庫
│ │ ├── index.ts # Client 端元件
│ │ ├── server.ts # Server 端元件
│ │ ├── components/
│ │ │ ├── client/ # Client 專用元件
│ │ │ └── server/ # Server 專用元件
│ │ └── styles/ # 共用樣式
│ ├── utils/ # 工具函數
└── …
這樣的架構讓我們可以清楚區分應用層與共用模組，當我們需要修改某個核心功能時，只要更新 libs/，所有應用程式都能同步獲得變更。
NX 的使用方式
1. 設定路徑別名
為了讓 apps/ 與 libs/ 的引用更直覺，我們在 tsconfig.base.json 中加入以下設定：
{
"paths": {
"@app1/*": ["apps/app1/*"],
"@app2/*": ["apps/app2/*"],
"@domain/*": ["libs/domain/*"],
"@api/*": ["libs/api/*"],
"@utils/*": ["libs/utils/*"]
...
}
}
這樣在專案內部就可以使用 @app1/、@domain/、@api/、@utils/ 等等來進行引用。
2. 生成 NX 應用與函式庫
生成新的應用程式（App）
nx g @nx/next:app apps/app
生成新的函式庫（Lib）
nx g @nx/next:lib libs/my-new-lib
這樣可以快速建立一個新的函式庫，供不同專案共用。
3. 查看所有可用目標
如果想知道專案 app1 內有哪些可用的目標（例如 build、test、serve 等），可以使用：
npx nx show project app1
這些目標可以是 NX 自動生成的，或者在專案內的 project.json 中定義的。
{
"name": "app1",
"$schema": "../../node_modules/nx/schemas/project-schema.json",
"sourceRoot": "apps/app1",
"projectType": "application",
"tags": [],
"// targets": "to see all targets run: nx show project app1--web",
"targets": {
//target 內可以自己定義需要的
}
}
下圖就是啟動nx show project app1 — web 後顯示的畫面
NX 帶來的效益
🚀提高開發效率
NX 提供了模組化管理，讓團隊可以更專注在各自的功能開發上，而不用擔心重複造輪子。
🎯 改善專案維護性
透過 libs/ 層的拆分，讓邏輯更容易管理，當某個功能需要變更時，不會影響到整個專案。
結論
這次將專案搬遷到 NX 讓我們體驗到 Monorepo 的威力，不僅能有效管理多個應用程式，還能提升開發效率。如果你的團隊也面臨相似的需求，NX 也許會是一個不錯的選擇。