What we're looking for is a way to build the dependencies of a package, without building the package - does that help?

Sorry the original post was confusing!

Ah, I see. This makes me think of two things:

• The ... microsyntax for --filter - but I can see how that would be insufficient if you want the task itself to always have this specifically defined behavior instead of with ad-hoc filters.
• With some creative script naming, you could do this:

// turbo.json
{
  "tasks": {
    "build:app": {
      "dependsOn": ["^build"]
    }
  }
}

Then, your app would have:

// apps/web/package.json
{
  "scripts": {
    "build:app": "the app's build script"
   }
}

And the libraries would have:

// packages/ui/package.json
{
  "scripts": {
    "build": "tsc"
    }
  }

Writing that out, it mostly strikes as a workaround without the feature you've proposed, but maybe that sounds sufficient to you? turbo run build would then only build dependent packages and turbo run build:app would build the app and dependent packages. Curious to hear your thoughts, as I could see this ending up in an inefficient mess of tricky script naming.

Thanks @anthonyshew, for now we've implemented a very similar pattern, but instead of renaming build, we've added a no-op script.

The app has a no-op script.

// apps/web/package.json
{
  "scripts": {
    "build": "next build",
    "build:deps": "exit 0;" // no-op
  }
}

That script has a dependency on dependencies being built.

// apps/web/turbo.json
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"]
    },
    "build:deps": {
      "dependsOn": ["^build"]
    }
  }
}

We depend on the "build:deps" no-op script:

// pw/e2e/turbo.json
{
  "tasks": {
    "e2e": {
      "dependsOn": ["web#build:deps"]
    }
  }
}

This works, but it would be nice if we could use the ^ alongside the arbitrary dependency's script/task.

(Side note: I just realised you can use jsonc instead of json in GitHub to allow comments not to show up as red errors!)