main.js(compiled js-files) file from a angular artifact replace in another build artifacts

Question

We have multiple environments, and we have environment files which having backend configarations and we are using these files during the builds. Example: ng build --c UAT

But I have a issue here, now we decided to build only once and deployment multiple environments same artifact.

I know this is quite achievable using an Angular service and the APP_INITIALIZER token, but some reason we can't use this.

So I decided to after the build, modify the compiled js files(main.js) with respective env configuration values. But it's becoming difficult because of increased number of env variable and its patterns.

So I thought of follow below process, please suggest it can usable or i should not

1, I'll build UAT webpack(dist/artifact) using the "ng build --c UAT".

2, I'll do same for all other environments, now I have total 3 dist folders(webpacks).

3, I'll deploy the UAT artifact to all environment s, but before deploying it to Preprod I'll replace "main.js" file with Preprod artifact main.js file because only main.js file have the all environment configarations. and keep all other js files same.

4, I'll repeat same with prod deployment.

Please suggest on this approach.

Answer 1

You made a good choice to decide against environment specific builds, as they'll always come back to haunt you. But with your approach you only shifted the problem since you still need to tweak the build artifact. When your configuration is highly dynamic, I would suggest to reconsider your decision of not using a Service to load the data dynamically at runtime, or at least state the constraints why this approach doesn't work for you.

Assuming you still want to rely on static file content, th article How to use environment variables to configure your Angular application without a rebuild could be of interest for you. It suggests to load the data from an embedded env.js script, and expose it from there as an Angular service. While one could argue that this also only shifts the problem further, it at least allows your build artifact to remain untouched. For example, if you run your app from say an nginx docker container, you could replace values in env.js dynamically prior to the webserver start. I'm using a simplified version of this approach, and while it still feels a bit hacky, it does work! Good luck!