包和任务图

包图

包图是由您的包管理器创建的 monorepo 结构。当您将内部包相互安装时，Turborepo 会自动识别这些依赖关系，从而构建对您的工作区的基本理解。

这为任务图奠定了基础，您将在其中定义任务之间的关系。

任务图

在 turbo.json 中，您表达了任务之间的关系。您可以将这些关系视为任务之间的依赖关系，但我们有一个更正式的名称：任务图。

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

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

您还有一个依赖于 ^build 的 build 任务

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

Turborepo 将构建如下所示的任务图

传递节点

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

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

Turborepo 将构建此任务图

您可以将此图看作一系列步骤

• docs 应用程序仅依赖于 ui。
• ui 包没有构建脚本。
• ui 包的依赖项有 build 脚本，因此任务图知道要包括这些依赖项。

Turborepo 在这种情况下将 ui 包称为传递节点，因为它没有自己的 build 脚本。由于它没有 build 脚本，Turborepo 不会对其执行任何操作，但它仍然是图的一部分，目的是包含其自身的依赖项。

传递节点作为入口点

如果 docs/ 包没有实现 build 任务会怎样？在这种情况下，您期望发生什么？ui 和 core 包是否仍应执行其构建任务？这里应该发生任何事情吗？

Turborepo 的心智模型是任务图中的所有节点都相同。换句话说，传递节点会包含在图中，而不管它们出现在图中的哪个位置。此模型可能会产生意想不到的后果。例如，假设您已将 build 任务配置为依赖于 ^test

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

假设您的 monorepo 有许多应用程序和许多包。所有包都有 test 任务，但只有一个应用程序有 build 任务。Turborepo 的心智模型表明，当您运行 turbo run build 时，即使应用程序没有实现 build，所有依赖项包的 test 任务也会显示在图中。