--extract-env flag for ng build

[rip222]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Description

Environment.ts files are useful. In my workflow I use a few of them (dev, test, pre-prod, prod). But recently the client requested some changes in environment file after the app was set to production. Also he wanted to have full control over the environment file for potential future changes. So the solution I came up with was not new : I've created a json file, added it to assets, and tied all the properties in the environment.ts file to that json file via http call at the start of the app.
The whole process is trivial, but cumbersome

Describe the solution you'd like

So what I propose is to add a flag for ng build or ng new, something like --extract-env, which would do exactly that: extract the environment.prod.ts file as a json file where I could make all the changes I wanted after building the app for production, like changing api endpoints, regexes etc.

Describe alternatives you've considered

Again, the alternative I'm going with right now is I create a special service for this operation, create a json file and add it to assets, create a special "init" function (APP_INITIALIZER) that fires before the app launches, makes an http call to that json file in assets and ties all the properties there to the environment.ts file.

[SchnWalter]

The environments file should be kept for pre-build flags and should not be mixed with run-time configuration that you might want to change after the build.

In our projects we've added the "post build" environment specific configuration to a JS file that that defines a global "APP_ENVIRONMENT_CONFIGURATION" variable defined as readonly in the coresponding app-environment-configuration.d.ts. And this file is loaded using a simple <script src="/environment/configuration.js"></script> added to index.html.

And to further improve this, we've also renamed the old environment.production flag to ENVIRONMENT.devMode. This way we avoid the confusion between the app specific "production" configuration defined in angular.json and the production flag verified when calling enableProdMode() and it's using SNAKE_CASE, since it's a constant.

L.E. See #3855, #7506, #7704

[alan-agius4]

Hi @rip222, as @SchnWalter, mentioned those options shouldn't be part of the build environments file, but have a runtime configuration.

In the above mentioned issues, there are some good approaches, example: #7506 (comment)

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