패키지 그래프

패키지 그래프는 패키지 매니저에 의해 생성된 모노레포의 구조입니다. 내부 패키지를 서로 설치하면 Turborepo는 자동으로 해당 의존성 관계를 식별하여 워크스페이스에 대한 기본적인 이해를 구축합니다.

이는 태스크가 서로 어떻게 관련되는지 정의할 태스크 그래프의 기초를 마련합니다.

태스크 그래프

turbo.json에서 태스크가 서로 어떻게 관련되는지 표현합니다. 이러한 관계를 태스크 간의 의존성으로 생각할 수 있지만, 우리는 이를 위한 더 공식적인 이름인 태스크 그래프를 사용합니다.

Turborepo는 리포지토리와 태스크를 이해하기 위해 방향성 비순환 그래프(DAG)라는 데이터 구조를 사용합니다. 그래프는 "노드"와 "에지"로 구성됩니다. 태스크 그래프에서 노드는 태스크이고 에지는 태스크 간의 의존성입니다. 방향성 그래프는 각 노드를 연결하는 에지에 방향이 있음을 나타내므로, 태스크 A가 태스크 B를 가리키면 태스크 A가 태스크 B에 의존한다고 말할 수 있습니다. 에지의 방향은 어떤 태스크가 어떤 태스크에 의존하는지에 따라 달라집니다.

예를 들어, ./apps/web에 두 개의 패키지 @repo/ui와 @repo/utils에 의존하는 애플리케이션이 있는 모노레포가 있다고 가정해 봅시다:

^build에 의존하는 build 태스크도 있습니다:

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

Turborepo는 다음과 같은 태스크 그래프를 구축합니다:

Transit 노드

태스크 그래프를 구축할 때의 과제는 중첩된 의존성을 처리하는 것입니다. 예를 들어, 모노레포에 ui 패키지에 의존하고, ui 패키지는 core 패키지에 의존하는 docs 앱이 있다고 가정해 봅시다:

docs 앱과 core 패키지는 각각 build 태스크를 가지고 있지만, ui 패키지는 가지고 있지 않다고 가정해 봅시다. 또한 위와 같이 "dependsOn": ["^build"]로 build 태스크를 구성하는 turbo.json이 있습니다. turbo run build를 실행하면 어떤 일이 일어날 것으로 예상하시나요?

Turborepo는 다음 태스크 그래프를 구축합니다:

이 그래프를 일련의 단계로 생각할 수 있습니다:

• docs 앱은 ui에만 의존합니다.
• ui 패키지는 빌드 스크립트를 가지고 있지 않습니다.
• ui 패키지의 의존성은 build 스크립트를 가지고 있으므로 태스크 그래프는 이를 포함하는 것을 알고 있습니다.

Turborepo는 이 시나리오에서 자체 build 스크립트를 가지고 있지 않기 때문에 ui 패키지를 Transit 노드라고 부릅니다. build 스크립트가 없기 때문에 Turborepo는 이를 위해 아무것도 실행하지 않지만, 자체 의존성을 포함하기 위한 목적으로 여전히 그래프의 일부입니다.

진입점으로서의 Transit 노드

docs/ 패키지가 build 태스크를 구현하지 않았다면 어떻게 될까요? 이 경우 어떤 일이 일어날 것으로 예상하시나요? ui 및 core 패키지가 여전히 빌드 태스크를 실행해야 할까요? 어떤 일이든 일어나야 할까요?

Turborepo의 정신 모델은 태스크 그래프의 모든 노드가 동일하다는 것입니다. 즉, Transit 노드는 그래프에서 어디에 나타나든 관계없이 그래프에 포함됩니다. 이 모델은 예상치 못한 결과를 가져올 수 있습니다. 예를 들어, build 태스크를 ^test에 의존하도록 구성했다고 가정해 봅시다:

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

모노레포에 많은 앱과 많은 패키지가 있다고 가정해 봅시다. 모든 패키지에는 test 태스크가 있지만 한 앱에만 build 태스크가 있습니다. Turborepo의 정신 모델에 따르면 turbo run build를 실행할 때 앱이 build를 구현하지 않더라도 의존성인 모든 패키지의 test 태스크가 그래프에 표시됩니다.