任务图

上一节 讨论了 Turborepo 如何使用 turbo.json 来表达任务之间的关系。您可以将这些关系视为任务之间的依赖关系，但我们对它们有一个更正式的名称：任务图。

Turborepo 使用一种称为 有向无环图 (DAG) (opens in a new tab) 的数据结构来理解您的存储库及其任务。图由“节点”和“边”组成。在我们的任务图中，节点是任务，边是任务之间的依赖关系。有向 图表示连接每个节点的边具有方向，因此如果任务 A 指向任务 B，我们可以说任务 A 依赖于任务 B。边的方向取决于哪个任务依赖于哪个任务。

例如，假设您有一个包含应用程序 apps/web 的 Monorepo，它依赖于两个包：@repo/ui 和 @repo/utils

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

以及一个 build 任务，它依赖于 ^build

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

Turborepo 将构建如下任务图

中转节点

在构建任务图时，一个挑战是处理嵌套依赖关系。例如，假设您的 Monorepo 有一个 docs 应用程序，它依赖于 ui 包，而 ui 包依赖于 core 包

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

假设 docs 应用程序和 core 包都有一个 build 任务，但 ui 包没有。您还有一个 turbo.json，它以与上面相同的方式配置 build 任务，使用 "dependsOn": ["^build"]。当您运行 turbo run build 时，您会期望发生什么？

Turborepo 将构建此任务图

您可以将此图视为一系列步骤

• docs 应用程序仅依赖于 ui。
• ui 包没有构建脚本。
• ui 包的依赖项 有一个 在这种情况中，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 任务也会出现在图中。

  任务依赖项过滤工作区