包和任务图

包图

包图是由你的包管理器创建的 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 有一个 docs 应用程序，它依赖于 ui 包，而 ui 包又依赖于 core 包

假设 docs 应用程序和 core 包各自都有一个 build 任务，但 ui 包没有。你还有一个 turbo.json，它以与上面相同的方式配置 build 任务，即 "dependsOn": ["^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 任务也会出现在图中。