Provide option to re-use configurations in angular.json

[PapaNappa]

I am working on a project with different languages.
This requires that each language is a separate configuration in the angular.json, eg

"configurations": {
  "prod-en": {
    "optimization": true,
    "outputHashing": "all",
    "sourceMap": false,
    "extractCss": true,
    "namedChunks": false,
    "aot": true,
    "extractLicenses": true,
    "vendorChunk": false,
    "buildOptimizer": true,
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ],
    "i18nLocale": "en",
    "baseHref": "/en/"
  },
  "prod-fr": {
    "optimization": true,
    "outputHashing": "all",
    "sourceMap": false,
    "extractCss": true,
    "namedChunks": false,
    "aot": true,
    "extractLicenses": true,
    "vendorChunk": false,
    "buildOptimizer": true,
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ],
    "i18nLocale": "fr",
    "baseHref": "/fr/"
  },
  …
]

This very soon becomes a maintenance nightmare and is definitely not DRY.
And all this only for enabling different languages.
The languages could be configured using ng build --i18n-locale=en …, but unfortunately ng serve does not provide these options.
(Before v6, i18n could be configured using CLI parameters for ng serve.)

This becomes worse when one wants to have a different set of options for ng serve (hashing, disable optimisations, source maps, etc.).
Then, one has to add another set of configurations (e.g. 'dev-en', 'dev-fr'), containing only the i18n options.

A third dimension (the first two being 'locale' and 'buildType') are different environment files.
Thus, if my application is deployed in three languages on three different environments, I need 9 different configurations for the build, and up to 9 more for local testing.

Thus, a mechanism to easily mix and match different sets of configurations would be great.
Or am I missing another feature that would solve my problem?

[elvisbegovic]

what about ng build -c=prod-fr (c = which configuration will be used ) then if you want you can still override them but with new syntax like you write in your angular.json file so i18nLocale inside your command:

ng build --i18nLocale=fr

[PapaNappa]

I know how to build these configurations. But as stated above (in my edited post), the current system can easily lead to (for example) 18 different configurations. And most of them share a large part.

This leads to a large angular.json file, which also is not very easy to read due to so man duplications. And editing all of them is error-prone. You might easily forget one config or mess something different up.

[PapaNappa]

@istiti (in reply to your edit): As I have written in my initial post, ng serve does not provide --i18nLocale, so I have duplications nevertheless.

So I could write different configurations for ng serve, but I don't need one configuration for every language for ng build. This would help a bit.

But still, I would have a some duplications for the different environment files, where only the environment file (in fileReplacements) differs, but all other build options stay the same.

[elvisbegovic]

apologize i still not understand, is this what you are speaking about: #10612

Why not putt other options inside build.options like :

And if you don't want write i18n specific to language inside angular.json you cant still write them inline in command
so package.json insdie scripts : "fr": "ng build --i18nLocale=fr (...and so on)",
then your file angular.json will be small :-D and you run build npm run fr

[PapaNappa]

Yeah, #10612 seems to be what I want.

---

Of course I can use ng build --i18nLocale, but I cannot use ng serve --i18nLocale, so I still need more configuration, bloating up the angular.json.

The issue is not only with languages, but generally with different build options, environments etc.

[angular-automatic-lock-bot]

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