NX does not handle multiple configurations: nx run app:build --configuration=production,stage-env

Expected Behavior

When running commands using nx, they should behave the same as ng

This works ng run app:build --configuration=production,stage-env

this does not nx run app:build --configuration=production,stage-env

Current Behavior

It seems that nx is stripping my extra stage-env configurations from the --configuration

Failure Information (for bugs)

I think it has to do with that in earlier version of the angular cli, multiple configurations where not supported, they where added here in November 2019 https://github.com/angular/angular-cli/pull/15819

The problem nx has, is that it only supports one config. https://github.com/nrwl/nx/blob/115a1abd75e3898beb3f91d93f4edc85b4b9a90b/packages/tao/src/commands/run.ts#L46 https://github.com/nrwl/nx/blob/115a1abd75e3898beb3f91d93f4edc85b4b9a90b/packages/tao/src/commands/run.ts#L120-L138

Solution

Change the implementation so that we are not limited to one config.

[georgiee]

Hello @FrozenPandaz , thanks for looking into this topic.

While I think your response fits 100% to what @leon intended to achieve it misses entirely the problem described in a linked “duplicate”. Please see my comment https://github.com/nrwl/nx/issues/4296#issuecomment-768894491 in #4296.

There are two type of requirements around this features:

• A) Being DRY with your configuration environment (stage, production etc)
• B) Mix environments and languages (production,fr etc).

Those are two entirely different problems. To be honest, to me A) makes little sense. I’m a fan of being explicit as this has the lowest level of cognitive load to my brain and makes reading code easier but it has its fans I’m sure.

But B) is almost an entirely different domain of problem. I absolutely need to mix my language configuration with different environments (development, staging, production) to serve or build the desired configuration. That feature of composing configurations always seemed really off to me. It’s like the Angular CLI team decided for the wrong location to place the language configuration but when you look into the details of what you can do with “locale” configuration it makes a little bit more sense again. For example your are allowed to change any configuration per locale (because it is a configuration) and one example is to change the main.ts per locale, outlined in one of the examples, do initialize your app differently per locale.

See this example: https://angular.io/guide/i18n#localize-build-command

"build": {
  ...
  "configurations": {
    ...
    "fr": {
      "localize": ["fr"],
      "main": "src/main.fr.ts",
      ...
    }
  }
},
"serve": {
  ...
  "configurations": {
    ...
    "fr": {
      "browserTarget": "*project-name*:build:fr"
    }
  }
}

A usual configuration rather looks like this:

   "i18n": {
  "sourceLocale": "en-US",
  "locales": {
    "fr": "src/locale/messages.fr.xlf",
    "de": "src/locale/messages.fr.xlf",
    "es": "src/locale/messages.fr.xlf"
  }
},
"architect": {
  "build": {
    "builder": "@angular-devkit/build-angular:browser",
    "options": {
    },
    "configurations": {
      "fr": {
        "localize": ["fr"]
      },
      "de": {
        "localize": ["de"]
      },
      "es": {
        "localize": ["es"]
      },

To build all of your locales you can do this:

yarn ng build --localize

but if you want to use only one locale you can also use the configuration composition:

yarn ng build --production,fr

this also works for serve if yo u set the appropriate locales:

"configurations": {
  "production": {
    "browserTarget": "i18example:build:production"
  },
   "fr": {
    "localize": ["fr"]
  },
  "de": {
    "localize": ["de"]
  },
  "es": {
    "localize": ["es"]
  },
}

yarn ng serve --fr

Here it falls apart.

yarn ng build --production,fr,de

If you chose to pass two locale-wise configurations to get two folders in dist: dist/de, dist/frin the production environment you might want to use this but that’s wrong as the composition doesn’t work in that extend. You need to create explicit options with "localize": ["es", "de"] in the angular.json.

You have already seen the property --localize. It is also exposed on the CLI level. You can use ng build --localize to use all locales available. It also seems to support to pass in an array --localize de,fr (see https://github.com/angular/angular-cli/blob/41a6fb82afa424c7bbbc9b9d40d8fde198d7ab55/packages/angular/cli/lib/config/schema.json#L2109-L2124) but the linked schema is only for the angular.json itself an describes the localize attribute and not the CLI option. So this fails yarn ng build --localize fr,de with unknown option fr,de.

---

Long story short, the configuration composition (that’s how Angular calls this) has a real impact on teams relying on the native i18n handling. I’m very much aware that the Angular CLI team has here a lot of potential to improve the API surface but it works. It just works and that’s why I would like to see Nx to support configuration composition. As said, yes, I can always pick ng to do the builds but I expected are more congruent API from Nx in this aspect.

Maybe you can evaluate your draft PR around providing this feature (https://github.com/nrwl/nx/pull/4889/files) again with those new information?

Thank you for considering this change in Nx 🙏

[leon]

I’ve done some more testing and have found that it’s --configuration that is causing the problem

if i do

-c production,test-env

it works but

---configuration production,test-env

does not work.

So it must be something to do with how we are passing along args.