GeezerVison is showing github.com — Mixing configurations · Issue #10612 · angular/angular-cli
Mixing configurations #10612DescriptionVersions
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 Reacted by Ryan Lester, Elvis Begovic, D, Jimmy Segers, Martin Nyolt, Radoslav Kirilov, Mick Lawitzke, Tomasz Błachut, Alireza Mirian, rmsmq and 127 more Reacted by Gautier P, Vasilis Diakomanolis, Klemen Oslaj, Максим Иванов, Ismael Ramos and Antonio Genaro Reacted by Rijin Elayambari, Gautier P, Vasilis Diakomanolis, Klemen Oslaj, Максим Иванов, Allen, Thomas Bianchi, Ismael Ramos, Yash Kadaru and Antonio Genaro Reacted by Gautier P, Robert J. Kusznier, Vasilis Diakomanolis, Gustav Bylund, ksz ksz, Klemen Oslaj, Максим Иванов, Allen, Ismael Ramos, Kai Lehmann and 4 more Reacted by Krzysztof Marian Raciniewski, Gautier P and Antonio Genaro Reacted by Gregory Zhukovsky, Tobias Friedinger, Marcus Abrahamsson, Tomas, Gautier P and Antonio Genaro Activityfilipesilva commented on May 3, 2018 phl3x0r commented on May 4, 2018 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 commented on Jun 14, 2018 Alternative to using multiple configurations they could have a extend feature as mentioned here: #11233 . Definitely need either one of them. MickL commented on Jun 14, 2018 @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... Reacted by Florian Reisecker, Tomasz Błachut, derdeka, Mohammed El Batya, Solution, Piotr Żurek, erex1, Kevin Kessenich, Vitaly Iegorov, Anders Törnkvist and 19 more phl3x0r commented on Jun 16, 2018 Looks like our situation. 30+ configurations x 6 different environments = wall of config rmsmq commented on Jul 27, 2018
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. Reacted by S. Mahdi Mir-Ismaili paulheising commented on Aug 16, 2018 +1
would definitely need such a feature! Reacted by Mohammed El Batya, M.Sakamaki, fimbulwint, Gautier P, erex1, Robin De Schepper, Atul Kumar, S. Mahdi Mir-Ismaili, Nitsan Baleli and gekkedev Reacted by Gregory Zhukovsky PhoneixS commented on Sep 26, 2018 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.
robertjk commented on Oct 1, 2018 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. Reacted by Andreas Osberghaus, Bart de Ruijter, Kansen, Alwin Schoemaker, Cédric Belin, S. Mahdi Mir-Ismaili, nomeaning, Gregory Zhukovsky, Salah Loukili, Summer Phillips and 1 more wulfsberg commented on Oct 6, 2018 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. Reacted by Niklas Hegnelt, Salah Loukili, dbPieter and Jakob Kofod Beyer splincode commented on Dec 26, 2018 @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",
(...)
}
}
}Reacted by Ringo , Spawnrad, Niklas Hegnelt, Kansen, Miguel Leon, Laurent Goudet, Dominic Foti Jr., Monwoo, Alexey, TMTron and 12 more phl3x0r commented on Jan 4, 2019 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. Reacted by Mick Lawitzke, Sergey Fetiskin, Dominic Foti Jr., Monwoo, Domas Trijonis, developer112, Radoslav Kirilov, Matt, Robin De Schepper, Pete and 23 more Reacted by Romko and Hung Q. Le Reacted by Ray Chavez, Aleksandr Vishniakov, Tadeusz and Julian abariatti commented on Aug 12, 2019
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? asvishnyakov commented on Aug 18, 2019 @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"Reacted by LAKE A. KAMSON, Yahya Uddin, Arnaud 2501, dodos90, Markus Hettich and Daniel Antenor Soares angular-automatic-lock-bot commented on Nov 14, 2019 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.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|