nx

nx copied to clipboard

• [x] 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

{
  "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": {}
    }
  }
}

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

{
  "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": {}
    }
  }
}

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

{
  "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": {}
    }
  }
}

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

Feb 19 '22 08:02 Bielik20

@FrozenPandaz Sorry for calling you out here, but this is important issue for us. I've created this issue as requested. I think I've presented my case well, given rationale and examples of behaviour. Is there something I can do to get more momentum for that?

Mar 04 '22 19:03 Bielik20

what does allowOverwrites even mean?

overwrite the output files?

overwrite the command arguments ?

overwrite the cache?

it's so confusing and i think that your solution is really only aimed at solving your personal use case.

Apr 24 '22 13:04 airtonix

@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.

Apr 25 '22 06:04 Bielik20

@FrozenPandaz Could we address this somehow? I have just made a jump from version 14.1.9 to 14.3.6 and now it doesn't even work for the same executor. I went through release changes but haven't seen anything that would touch upon this.

Again, I am willing to make a PR with the "Alternate Implementations". I must sadly say that this is not the first time that dependsOn breaks in the update. I would be nice to finally craft some more clear rules for it.

Jun 23 '22 10:06 Bielik20

I have almost the same use case. Hoping to forward args.stage to the fetch-params target, but it reads undefined

Tried adding "forwardAllArgs": true but no dice.

Thanks!

EDIT: seems like #11014 also addresses this

Jul 07 '22 19:07 leggomuhgreggo

• 1 here. I have the same problem that the args are not forwarded

Jul 29 '22 08:07 chrizza87

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

Aug 08 '22 02:08 JakeGinnivan

This issue has been automatically marked as stale because it hasn't had any recent activity. It will be closed in 14 days if no further activity occurs. If we missed this issue please reply to keep it active. Thanks for being a part of the Nx community! 🙏

Apr 16 '23 00:04 github-actions[bot]

Fighting the stale bot.

Apr 16 '23 13:04 Bielik20

Is this working now? I'm looking at this:

https://nx.dev/reference/project-configuration#dependson

And it says you can configure the behavior of params forwarding for depends on like:

"dependsOn": [{"projects": "self", "target": "build", "params": "forward"}],

And I just tested it and it works!

Nov 06 '23 19:11 chriszrc