Caret (^) isn't correctly evaluated for phantom Turbo tasks

[JavaScriptBach]

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/JavaScriptBach/turbo-caret-bug

Which canary version will you have in your reproduction?

2.4.5-canary.1

Enviroment information

turbo 2.4.5-canary.1

CLI:
   Version: 2.4.5-canary.1
   Path to executable: /Users/philliphuang/turbo-caret-bug/node_modules/turbo-darwin-arm64/bin/turbo
   Daemon status: Running
   Package manager: berry

Platform:
   Architecture: aarch64
   Operating system: macos
   WSL: false
   Available memory (MB): 2969
   Available CPU cores: 10

Environment:
   CI: None
   Terminal (TERM): xterm-256color
   Terminal program (TERM_PROGRAM): Apple_Terminal
   Terminal program version (TERM_PROGRAM_VERSION): 455
   Shell (SHELL): /bin/zsh
   stdin: false

Expected behavior

In my repository, I have tasks defined in turbo.json that contain a dependsOn but don't have an accompanying implementation in package.json. I use these "phantom" tasks as a way to specify relationships between real tasks and also to DRY between many packages in a mono-repo.

The problem is that the caret (^) behavior is not correctly evaluated when running a phantom task. If I have packages a, b, c where c depends on b which depends on a, then running turbo c#my-task does not run a's tasks, even when the dependency chain is properly set up.

See https://github.com/JavaScriptBach/turbo-caret-bug

Actual behavior

See https://github.com/JavaScriptBach/turbo-caret-bug

To Reproduce

See https://github.com/JavaScriptBach/turbo-caret-bug

Additional context

No response

[NicholasLYang]

Hi, thanks for the issue. I think I see the problem.

    "build:app:recursive": {
      "dependsOn": ["^build:app", "build:app"]
    }

This task definition declares that for a given build:app:recursive task, e.g. c#build:app:recursive, the task depends on the package's dependencies' build:app tasks, e.g. b#build:app since c depends on b. We call these topological dependencies. However, that does not mean that c#build:app:recursive depends on a#build:app:recursive, because a is not a direct dependency of c. For that to work, you need to add the following:

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

This declares that each build:app task always depends on its package's dependencies build:app.

Let me know if that makes sense or if I missed something!

[JavaScriptBach]

I see, I think I misinterpreted how caret works then. I thought ^build:app meant "recursively depends on build:app in the package's dependency tree", but it sounds like it only checks one layer. I'll need to re-work how I can define my turbo file then.

For more context, it's not correct for me to say that build:app depends on ^build:app. build:app is a task that transpiles the ts in that package to js; it doesn't need to depend on a package's dependency tree.

However, some tasks need the ability to say that "I depend on the recursive transpilation of package Foo along with its dependency tree". In order to accomplish this, I defined the phantom task build:app:recursive that depends on build:app and ^build:app but it looks like that doesn't work per your explanation above. Thanks.

[JavaScriptBach]

OK, I was able to fix my Turbo file to my liking. Thanks @NicholasLYang for your help.

Would you consider changing the documentation in https://turbo.build/repo/docs/crafting-your-repository/configuring-tasks#depending-on-tasks-in-dependencies-with-?

The ^ microsyntax tells Turborepo to run the task starting at the bottom of the dependency graph. If your application depends on a library named ui and the library has a build task, the build script in ui will run first. Once it has successfully completed, the build task in your application will run.

"Bottom of the dependency graph" sounds like it is doing some sort of recursive dependency lookup, but that's not what's happening here.

[anthonyshew]

@JavaScriptBach, thank you for pointing that out. Will fix as soon as I can.