Allow task names with wildcards in pipeline definition

[beeequeue]

Describe the feature you'd like to request

We have two main types of workspaces in our monorepo: packages and microfrontends. These two types each require different dependsOn configurations, but from what I can see in the documentation this is not possible to do.

Describe the solution you'd like

I propose being able to use the new --filter syntax in the Pipeline name configs:

"./microfrontends/*#build": {
  "dependsOn": [
    "$APP_ENV",
    "src/**",
    "webpack.config.*"
  ],
  "outputs": ["dist/**"]
},
"./packages/*#build": {
  "dependsOn": [
	"$NODE_ENV",
    "src/**"
  ],
  "outputs": ["dist/**"]
},
"build": {
  "dependsOn": [
    "src/**"
  ],
  "outputs": ["dist/**"]
},

Describe alternatives you've considered

It would be nice to at the very least have globs work in the names: @mf/*#build. Then we could name every workspace differently to handle these cases.

Another option would be to not require every string in dependsOn to match a file, then any missing files would be hashed as empty or something similar.

[silesky]

This may be related to a scenario I'm researching!

My workspaces are contained in ./examples/** and ./packages/**. I want to create a lint command that lints everything, but only dependsOn ./packages (since examples depend on packages, but no example or package depends on any example). AFAIK, I currently have to name every repo in ./packages explicitly, like:

    "lint": {
      "dependsOn": [
        "package1#build",
        "package2#build",
        "package3#build",
        "package4#build",
      ],
      "outputs": [],
    }

I would like to do something like:

    "lint": {
      "dependsOn": [
        "./packages/**#build
      ],
      "outputs": [],
    }

[mehulkar]

I've renamed this issue to more generally be about wildcarding, even though the original issue was specifically about using directory paths, rather than package names in the task definitions.

[psychobolt]

Should we support single asterisk notation? If so, there could be a collision with: #4145

[mehulkar]

#4145's proposed solution may conflict, that's a good call out, but I think that issue is asking for a general "finalization" API. I think that could be a good feature as well, and we should take that into account when designing the API.

The next step would be to outline the scope of this API and (as @psychobolt mentioned) where it could overlap with other features. Off the top of my head, dependsOn should be able to declare:

• More than one task name with a wildcard (e.g. build:*)
• More than one package name with a wildcard (e.g. ui-*:build)

It could overlap with:

• Finalization chains (e.g. dependsOn: ["**everything**"]) Allow root task to have dependsOn: ["*"] #4145
• turbo run foo* (Expand tasks w/glob #1029)