A common management issue for coder is automation to cherry-pick environment-specific configurations for bundling and release of build package. At the end of this article, you will know and find code references to fully customize your staging environment and release package settings.
You have different environments such as staging, development, production or ci or more depending on the project. The main package management usually concerning is which settings, assets to include and exclude.
In development maybe you will use dummy data and dummy assets to play around whereas when you release your build package to your end user, you will exclude those mock data. Also, in production you may have apply certain real setting but in development or staging you will set another settings.
In this sharing you will learn a way to solve all your bundling problem on which angular-cli.json config to include/exclude and which setting to change based on the environment. This approach can also be extended to other files like other webpack or json config.
The final code available here.
git clone --branch feature/custom-cli-configuration https://github.com/seanlon/demo-angular-app/
At image below, first , we look at certain folder and file to include when development/staging package build. Then also notice the production/release file specific is different for production/release environment. However, there is a common file to include for both the environment.
Next, we aim to build our own setting file angular-cli.json for the environment. We will give the file a suffix ‘dev‘ and ‘prod’. We also place them in a proper folder.
After that , we create a node script build-config.js which will accept a parameter for environment build – ‘dev’ or ‘prod’, and overwrite the default angular-cli.json accordingly.
After that , we configure our package.json for different environment build.
Now we run our build for dev staging build release.
Notice our distribution dist folder is correctly including resources we want.
Now we run our build for prod production build release.
We get the correct result too.
Looking at our angular-cli.json, we see it updated correctly too base on the environment.
Now imagine, what other powerful configuration we can extend it to do too.
In most cases, we do
not want to overhead our repository with large configurations and so keeping duplicate environment files is not good.
If you like this article, please share and comment.