Mixing configurations

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

@buu700

@buu700 was also interested in something similar in #10559

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

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

@hansl

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

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

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.

+1

would definitely need such a feature!

I think that it should be mentioned in the documentation in Deployment because nowadays it is in i18n:

For production builds, you define a separate production-fr build configuration in the CLI configuration file, angular.json.

I also think this feature is essential to write maintainable, clean configurations, especially when you implement internationalization.

I wonder if this problem could also be solved by allowing angular.json to be written in YAML (angular.yaml), as YAML lets you declare anchors to duplicate properties.

@MickL

I agree with @MickL that this is beyond a "nice to have". Even something as trivial as changing the default locale (for pipes) explodes into a barrage of cut'n'paste all over the already-not-too-friendly angular.json.

@mgechev

@mgechev it would be cool to be able to inherit

"build": {
  ...
  "configurations": {
    "production": {
      (...)
    },
    "pl": {
      "extends": "config/pl.angular.json",
      (...)
    },
    "en": {
      "extends": "config/en.angular.json",
      (...)
    }
  }
}

I think this issue needs more attention.
Our angular.json file is currently 14048 lines and growing, not even counting the multitude of i18n configurations that are yet to be implemented.

@asvishnyakov

I compile it and run as node angular.js before build and serve commands (I use npm run build, npm run start which internally call this task).

@asvishnyakov Would you have the awesomness of providing a running gist?

@abariatti

@abariatti I cannot show you full code because of my contract limitations, but the idea is simple.

Add angular.ts and put your current json to it as typescript object, i.e.

const angularJson = { ... };

Then add output to the angular.json:

const fs = require('fs');
const angularJson = { ... };
fs.writeFileSync('angular.json', JSON.stringify(angularJson, null, 4), 'utf8');

Now, in packages.json add tasks to compile and run it:

{
  "scripts": {
    "angular-json:build": "tsc --moduleResolution node --lib es2018 --outFile angular.js angular.ts",
    "angular-json:transform": "npm run angular-json:build && node angular.js",

Then run angular-json:transform task manually every time you change angular.ts or add it before every build or run task in packages.json:

{
  "scripts": {
    "build": "npm run angular-json:transform && ng build"

feat(@angular/cli): support using multiple configurations

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

feat(@angular/cli): support using multiple configurations

Navigation Menu

Repository navigation

Mixing configurations #10612

Versions

Observed behavior

Desired behavior

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Mixing configurations #10612

Description

Versions

Observed behavior

Desired behavior

Activity

filipesilva commented on May 3, 2018

phl3x0r commented on May 4, 2018

MickL commented on Jun 14, 2018

MickL commented on Jun 14, 2018

phl3x0r commented on Jun 16, 2018

rmsmq commented on Jul 27, 2018

paulheising commented on Aug 16, 2018

PhoneixS commented on Sep 26, 2018

robertjk commented on Oct 1, 2018

wulfsberg commented on Oct 6, 2018

splincode commented on Dec 26, 2018

phl3x0r commented on Jan 4, 2019

13 remaining items

abariatti commented on Aug 12, 2019

asvishnyakov commented on Aug 18, 2019

angular-automatic-lock-bot commented on Nov 14, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions