Turbo running incorrect scripts from root based on dependsOn

[w-a-t-s-o-n]

Summary

Title was a little weird to try to come up with, but basically when I run a particular Turbo script from the root, and only one package in the monorepo has that script, it's running something it shouldn't. If I add a filter to it, it works fine. This will be easier to show:

packages

(all have a build script)

• packages/tokens: no test script
• packages/icons: no test script
• packages/design-system: includes test script, and has tokens and icons as dependencies
• packages/other-package: no test script, depends on design-system

root package.json

  "scripts": {
    "build": "turbo run build",
    "test": "turbo run test"
  },

turbo.json

{
  "pipeline": {
    "build": {
      "dependsOn": [
        "^build"
      ],
      "outputs": [
        "dist/**"
      ]
    },
    "test": {
      "dependsOn": [
        "^build"
      ]
    }
  }
}

Expectations

When I run either pnpm test or pnpm test -- --filter=design-system:

1. tokens and icons should build
2. test should be executed on design-system

This does happen if I include the --filter=design-system, however if I omit the filter, a third step happens:
3. build is executed on design-system

Since I used ^build in the test.dependsOn, I don't expect design-system to build.

Any ideas why it changes based on the filter in this situation since there is only one package that includes the test script?

Additional information

No response

Example

https://github.com/w-a-t-s-o-n/turbo-building-when-it-shouldnt/tree/main

[w-a-t-s-o-n]

I should probably add that there are other packages that depend on design-system, but they do not have the test script either.

[anthonyshew]

Do you have a reproduction link you could share?

[w-a-t-s-o-n]

I'm not sure I follow this logic. My understanding of "^build" is that it builds the dependencies of the packages that the task is running on. In this case test should only run on tokens, icons, and design-system. Neither tokens nor icons have a dependency of design-system, so I don't understand why design-system is building. This only happens when the other-package with a dependency of design-system is added that does not have a test script. I don't see a logical reason for design-system to build in this case since the other-package is not executing any tasks.

But maybe there's something I'm missing? Should turbo care about the dependencies of packages that are not executing tasks and are not dependencies of any relevant packages? In this case this leads to longer execution time for the test script than necessary since I do not need design-system to build because it's a dependency of a package that I'm not testing.

[w-a-t-s-o-n]

Unmarked answer in hopes I'll get some more info on this as I'm still a bit confused.

[w-a-t-s-o-n]

@anthonyshew any chance I could get an explanation as to why adding a package without a test script that has a design-system dependency affects how the dependsOn scripts are run when I do turbo run test? Is there a different config option besides ^build that I should be using instead so that turbo only builds dependencies of the packages that include a test script?

[anthonyshew]

A package is included in the graph if it has a dependency relationship through package.json, even if it doesn't have a test script. We call these "Transit Nodes": https://turbo.build/repo/docs/core-concepts/monorepos/task-graph#transit-nodes

[w-a-t-s-o-n]

Interesting. I was familiar with this concept as it relates to sub-dependencies of packages with the task you're running. I guess I didn't realize that turbo would use a transit node/package without that script as an entry point, but the very last sentence on that page seems to cover this case. I guess this is just an unfortunate limitation of turbo.

I would be curious to know the advantage of adding dependencies of transit nodes (as entry points) to the task graph when they are unrelated to what you're trying to execute but at least I can see now that this is intentional.

It would be nice to have a way to disable this functionality in the config for certain tasks so that I don't have to maintain filters whenever we add more packages with test scripts to avoid extraneous builds.