Mixing configurations

[ocombe]

Versions

v6

Observed behavior

You cannot use --prod with a custom configuration since --prod is an alias for --configuration=production. This means that if I make a custom configuration for my project, I need to duplicate it for the prod build to include everything from the production configuration.

Desired behavior

I'd like to be able to mix configurations, where each one overwrites the precedent. For example with -c=prod,xxx, where xxx overwrites production values if they both define the same property

For example if I'm doing i18n, I would like to have something like that:

          "configurations": {
            "production": {
              "fileReplacements": [
                {
                  "replace": "src/environments/environment.ts",
                  "with": "src/environments/environment.prod.ts"
                }
              ],
              "optimization": true,
              "outputHashing": "all",
              "sourceMap": false,
              "extractCss": true,
              "namedChunks": false,
              "aot": true,
              "extractLicenses": true,
              "vendorChunk": false,
              "buildOptimizer": true
            },
            "fr": {
              "aot": true,
              "outputPath": "dist/my-project-fr/",
              "i18nFile": "src/locale/messages.fr.xlf",
              "i18nFormat": "xlf",
              "i18nLocale": "fr",
              "i18nMissingTranslation": "error"
            }
          }
        },

And use -c=production,fr, or --prod -c=fr

[filipesilva]

@buu700 was also interested in something similar in #10559

[phl3x0r]

That would be a great addition.
At the moment (in the 1.x.x config) I have a setup with many apps sharing a lot of the same (duplicate) configuration. I was hoping that 6.0 would provide a way to share common configuration between app flavors, but at this point, the config will just be even more bloated than before.
In my case it's not the i18n files (although potentially it will be in the future), but assets, styles and environment files that changes between customers (apps).

[MickL]

Alternative to using multiple configurations they could have a extend feature as mentioned here: #11233 . Definitely need either one of them.

[MickL]

@hansl Personally i would set this issue to priority 2 (required). Instead of:

ng build -c=prod,theme1,en and ng serve -c=theme1,en

we have to make TONS configurations with TONS of duplicate code:

"build": {
   ...
    "configurations": {
        "theme1": {
            // Asset configuration theme 1
        },
        "theme1-en": {
            // Asset configuration theme 1
            // Load language files EN
        },
        "theme1-prod-en": {
            // Production settings
            // Asset configuration theme 1
            // Load language files EN
        },
        "theme1-de": {
            // Asset configuration theme 1
            // Load language files DE
        },
        "theme1-prod-de": {
            // Production settings
            // Asset configuration theme 1
            // Load language files DE
        },
         "theme2": {
            // Asset configuration theme 2
        },
        "theme2-en": {
            // Asset configuration theme 2
            // Load language files EN
        },
        "theme2-prod-en": {
            // Production settings
            // Asset configuration theme 2
            // Load language files EN
        },
        "theme2-de": {
            // Asset configuration theme 2
            // Load language files DE
        },
        "theme2-prod-de": {
            // Production settings
            // Asset configuration theme 2
            // Load language files DE
        },
    }
},
"serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": {
        "browserTarget": "myapp:build"
    },
    "configurations": {
        "theme1": {
            "browserTarget": "myapp:build:theme1"
        },
        "theme1-en": {
            "browserTarget": "myapp:build:theme1-en"
        },
        "theme1-de": {
            "browserTarget": "myapp:build:theme1-de"
        },
        "theme1-prod-en": {
            "browserTarget": "myapp:build:theme1-prod-en"
        },
        "theme1-prod-de": {
            "browserTarget": "myapp:build:theme1-prod-de"
        },
        "theme2": {
            "browserTarget": "myapp:build:theme2"
        },
        "theme2-en": {
            "browserTarget": "myapp:build:theme2-en"
        },
        "theme2-de": {
            "browserTarget": "myapp:build:theme2-de"
        },
       "theme2-prod-en": {
            "browserTarget": "myapp:build:theme2-prod-en"
        },
        "theme2-prod-de": {
            "browserTarget": "myapp:build:theme2-prod-de"
        },
    }
}

And this was just 2 themes and 2 languages. It multiplies for each other theme or language...

[phl3x0r]

Looks like our situation. 30+ configurations x 6 different environments = wall of config

[rmsmq]

Alternative to using multiple configurations they could have a extend feature as mentioned here: #11233 . Definitely need either one of them.

Unless I am misunderstanding, I don't think this will reduce the number of configurations, only duplication within the configurations.

I would prefer the proposed solution in this issue, which should allow for significantly less configurations.

[paulheising]

+1

would definitely need such a feature!