Pass overrides to targetDependencies/dependsOn tasks

• I’d be willing to implement this feature (contributing guide)

Description

I would like for dependant tasks to be able to receive overrides. Having configuration like so:

{
  "root": "apps/api",
  "sourceRoot": "apps/api/src",
  "projectType": "application",
  "prefix": "api",
  "targets": {
    "build": {
      "executor": "api-executors:build",
      "outputs": ["{options.outputPath}"],
      "options": {}
    },
    "deploy": {
      "executor": "api-executors:deploy",
      "dependsOn": [
        {
          "target": "build",
          "projects": "self"
        }
      ],
      "options": {}
    }
  }
}

I would like running nx run api:deploy --stage my-branch-name // dynamic - cannot be solved with configuration

To result in:

nx run api:build --stage my-branch-name
nx run api:deploy --stage my-branch-name

Motivation

I have been trying to get on board using targetDependencies/dependsOn since it was released but I still can’t because of the limitations in how overrides are treated. With Nx v14 coming probably soon, the --with-deps will disappear so this becomes more crucial.

The most obvious use case is the one I present in the description. Having deploy and build targets that both depend on stage flag which can be anything (like a branch name). Another similar use case would be having 2 separate apps with different deploy executors, but one depends on the other (like having 2 microservices where the first depends on the existence of the other).

Suggested Implementation

I took liberty to create a simple solution here: https://github.com/nrwl/nx/pull/9026

Alternate Implementations

Since I am opening a discussion about it, I would like to suggest something more radical:

• All overrides are passed by default (this is opposite of the current behaviour)
• There is a field allowOverrides in target definition that serves as a discriminatory whitelist.
  • If there is no allowOverrides field all overrides are passed to this target.
  • If there is allowOverrides field only overrides in that list are accepted. That remains true also for the initial target.

This would still allow for many cache hits while giving us a lot control over which properties we allow to overwrite.

Examples

Default - no allowOverrides

{
  "root": "apps/api",
  "sourceRoot": "apps/api/src",
  "projectType": "application",
  "prefix": "api",
  "targets": {
    "build": {
      "executor": "api-executors:build",
      "outputs": ["{options.outputPath}"],
      "options": {}
    },
    "deploy": {
      "executor": "api-executors:deploy",
      "dependsOn": [
        {
          "target": "build",
          "projects": "self"
        }
      ],
      "options": {}
    }
  }
}

Running: nx run api:deploy --foo foo --bar bar

Results in:

nx run api:build --foo foo --bar bar
nx run api:deploy --foo foo --bar bar

Child target accepts all, Parent accepts none

{
  "root": "apps/api",
  "sourceRoot": "apps/api/src",
  "projectType": "application",
  "prefix": "api",
  "targets": {
    "build": {
      "executor": "api-executors:build",
      "outputs": ["{options.outputPath}"],
      "options": {}
    },
    "deploy": {
      "executor": "api-executors:deploy",
      "allowOverrides": [],
      "dependsOn": [
        {
          "target": "build",
          "projects": "self"
        }
      ],
      "options": {}
    }
  }
}

Running: nx run api:deploy --foo foo --bar bar

Results in:

nx run api:build --foo foo --bar bar
nx run api:deploy

Child and parent accept different params

{
  "root": "apps/api",
  "sourceRoot": "apps/api/src",
  "projectType": "application",
  "prefix": "api",
  "targets": {
    "build": {
      "executor": "api-executors:build",
      "allowOverrides": ["foo"],
      "outputs": ["{options.outputPath}"],
      "options": {}
    },
    "deploy": {
      "executor": "api-executors:deploy",
      "allowOverrides": ["bar"],
      "dependsOn": [
        {
          "target": "build",
          "projects": "self"
        }
      ],
      "options": {}
    }
  }
}

Running: nx run api:deploy --foo foo --bar bar

Results in:

nx run api:build --foo foo
nx run api:deploy --bar bar

[Bielik20]

@airtonix That was a typo on my part, obviously I meant overrides. Overrides as defined in source code as: https://github.com/nrwl/nx/blob/8c38b8618d111b14e9b9574c4a818b9c685b49cd/packages/nx/src/tasks-runner/run-command.ts#L268-L271

Are params you pass to executor to override default settings nx run my-app:serve --foo bar, here --foo bar is an override.

Currently there is an arbitrary rule that passes all overrides to a target that uses the same executor. I think this is confusing and very limiting. With cool features like dependsOn we should have more control over how we treat overrides. deploy target that depends on build is just one example. I went through some other issues in repository and found at least few that could benefit. Plus, I don’t think that additional control and verbosity is confusing, quite the opposite of that.

[JakeGinnivan]

https://github.com/nrwl/nx/pull/11418 I’ve got a related PR open here.