Nx: Cannot pass in multiple configurations using -c since nx 11

[leon]

Current Behavior

nx run app-api:build -c=production,dev-environment 

Could not find configuration "production,dev-environment" in app-api:build. Valid configurations are: dev-environment, production

Expected Behavior

should be the same as running

nx run app-api:build --configuration=production,dev-environment

this works and applies both production and dev-environment configurations

Steps to Reproduce

create multiple configurations for a app.
then apply them both using

-c=config1,config2

This issue may not be prioritized if details are not provided to help us reproduce the issue.

Failure Logs

Could not find configuration "production,dev-environment" in app-api:build. Valid configurations are: dev-environment, production

Environment

Node : 14.15.1
  OS   : darwin x64
  yarn : 1.22.10

  nx : Not Found
  @nrwl/angular : 11.0.4
  @nrwl/cli : 11.0.4
  @nrwl/cypress : 11.0.4
  @nrwl/devkit : 11.0.4
  @nrwl/eslint-plugin-nx : Not Found
  @nrwl/express : Not Found
  @nrwl/jest : 11.0.4
  @nrwl/linter : 11.0.4
  @nrwl/nest : 11.0.4
  @nrwl/next : Not Found
  @nrwl/node : 11.0.4
  @nrwl/react : Not Found
  @nrwl/schematics : Not Found
  @nrwl/tao : 11.0.4
  @nrwl/web : Not Found
  @nrwl/workspace : 11.0.4
  typescript : 4.0.5

[yjaaidi]

This is where it happens:

https://github.com/nrwl/nx/blob/2651ff98f33de251438601bc75a96fff764ba93e/packages/tao/src/commands/run.ts#L111:L123

Should tao merge the configurations?

I'd be happy to help with a PR.

[vsavkin]

Folks. I reconciled the difference between -c and --controller. The fix is in 11.0.8.

I'm sorry but we won't be supporting it multiple configs in a single command. The workaround is to run the command twice.

Let me explain why, so hopefully the decision won't seem arbitrary.

Running multiple configurations is straightforward when you do it against a single project, but often commands build/test multiple projects. Consider, for instance: ng build myapp --with-deps --configuration=production. This will build the app and all the libs it depends on. Those libs might not have the production configuration. So Nx requires the production configuration to be available for the app, but not for the libs. The libs are also built in a particular order. We are dealing with a build graph that we need to process in a particular order.

ng build myapp --with-deps --configuration=conf1,conf2 --skip-nx-cache is more complicated. Should we build the libs once or twice? What if some libs have conf1 but conf2, some have conf2 but not conf1. Should I build the libs first and then the apps? We have two dimensions here (projects and configurations) and it complicates things. It's of course possible to pick some answers, but they won't be self evident. They will have to be documented etc..

Given that the use case is somewhat rare and the workaround is straightforward (run the command twice), from now on we will only support one configuration per run.

For now I'm going to close the issue. If the workaround doesn't around, please reopen the issue let me know the details, and I'll reassess the situation.

And apologies for breaking -c.

[dogmatico]

For us, this change broke the build pipeline as it was incompatible with the ng default behaviour of composing configuration using left to right patching. In particular, in a single tenant app with multiple deployments, we were composing production with a customer specific configuration that just changed the fileReplacements key.

With v10 patching of ng, calling the local ng -- --c=production,config-1 was compatible with the standard ng behaviour. With v11, no. We are bypassing the ng patch just for the build of the application and using the nx command for the other relevant stuff like testing and linting.

[henry-martinez]

@vsavkin

This too, broke our build pipeline. We use nx affected:build -c=production,dev1. "dev1" only uses deployUrl to point to our dev1 url path. This setup has worked beautifully so that we don't have to duplicate all the "production" configurations in each and every dev config.. We have around 12 dev configs per app and a few dozen apps, so this multiplies really fast and the config merging saves a lot of replication and maintenance.

Regarding your workaround to "run twice", I'm not sure I follow how that would apply to our use case. Can you elaborate?
Seems like that would create a lot of unnecessary build time overhead.

Cheers!