工作圖

上一節討論了 Turborepo 如何使用 turbo.json 來表達任務之間的關聯性。你可以將這些關聯性視為任務之間的依賴關係，但我們有更正式的名稱：任務圖形。

Turborepo 使用稱為 有向無環圖 (DAG)（在新分頁中開啟） 的資料結構來了解你的儲存庫及其任務。圖形由「節點」和「邊緣」組成。在我們的任務圖形中，節點是任務，而邊緣是任務之間的依賴關係。有向圖形表示連接每個節點的邊緣具有方向，因此如果任務 A 指向任務 B，我們可以說任務 A 依賴於任務 B。邊緣的方向取決於哪個任務依賴於哪個任務。

例如，假設你有一個單一儲存庫，其中包含應用程式 apps/web，它依賴於兩個套件：@repo/ui 和 @repo/utils

my-monorepo
└─ apps
 └─ web
└─ packages
 └─ ui
 └─ utils

以及依賴於 ^build 的 build 任務

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"]
    }
  }
}

Turborepo 會建立如下所示的任務圖形

中繼節點

在建立 Task Graph 時，處理嵌套相依性是一個挑戰。例如，假設您的 monorepo 有個 docs 應用程式，它相依於 ui 套件，而後者又相依於 core 套件

my-monorepo
└─ apps
 └─ docs
└─ packages
 └─ ui
 └─ core

假設 docs 應用程式和 core 套件各有 build 工作，但 ui 套件沒有。您也有個 turbo.json，它設定 build 工作的方式與上述相同，並使用 "dependsOn": ["^build"]。當您執行 turbo run build 時，您會預期發生什麼事？

Turborepo 將建立這個 Task Graph

你可以將此圖表視為一系列的步驟

• docs 應用程式僅依賴於 ui。
• ui 套件沒有建置指令碼。
• ui 套件的相依性具有 build 指令碼，因此任務圖表知道要包含這些相依性。

在這個範例中，Turborepo 將 ui 套件稱為中繼節點，因為它沒有自己的 build 指令碼。由於它沒有 build 指令碼，因此 Turborepo 對於它不會執行任何操作，但它仍然是圖表的一部分，目的是包含它自己的相依性。

如果我們不將中繼節點包含在圖表中，會怎樣？

在上述範例中，我們將 ui 節點（及其相依性）包含在任務圖表中。這是要確保 Turborepo 在你預期時錯過快取的重要區別。

如果預設值是排除中繼節點，則 core 套件中的原始碼變更不會使 docs 應用程式快取無效，以使用 turbo run build，使用 core 套件先前反覆運算的過時程式碼。

中繼節點作為進入點

如果 docs/ 套件未實作 build 任務，會發生什麼事？您預期會發生什麼情況？ui 和 core 套件是否仍會執行它們的建置任務？這裡是否應該發生任何事？

Turborepo 的心智模型是，任務圖表中的所有節點都是相同的。換句話說，不論中繼節點在圖表中出現在哪裡，都會包含在圖表中。此模型可能會造成意外的後果。例如，假設您已將 build 任務設定為依賴 ^test

{
  "pipeline": {
    "build": {
      "dependsOn": ["^test"]
    }
  }
}

假設你的單一儲存庫有許多應用程式和許多套件。所有套件都有 test 任務，但只有一個應用程式有 build 任務。Turborepo 的心智模型表示，當你執行 turbo run build 時，即使應用程式未實作 build，所有相依套件的 test 任務也會顯示在圖形中。