Thanks for the reply. Considering that these are runtime configs, one method you can use is creating the runtime-config.js file as part of the deployment pipeline.
I like to keep the config files per environment organized in json in my repository, so one method that I like to use is to have a different json file per environment (dev.config.json, stg.config.json, prod.config.json) making sure the file name is the same as the environment name and keeping the property names consistent
Ex dev json:
{
"apiUrl": "testing.mattcat.dev"
}
Ex prod json:
{
"apiUrl": "prod.mattcat.dev"
}
Then during the deployment pipeline as a step, calling a bash script to read in the proper environment json file and create the runtime-config.js file.
Thanks for the reply. Considering that these are runtime configs, one method you can use is creating the
runtime-config.js
file as part of the deployment pipeline.I like to keep the config files per environment organized in json in my repository, so one method that I like to use is to have a different json file per environment (dev.config.json, stg.config.json, prod.config.json) making sure the file name is the same as the environment name and keeping the property names consistent
Ex dev json:
Ex prod json:
Then during the deployment pipeline as a step, calling a bash script to read in the proper environment json file and create the
runtime-config.js
file.The bash script looks something like this:
Calling it like this during your deployment pipeline
BUILD_ENV=stg ./config-expansion.sh
I am sure you can find other ways to generate the run-config.js file but this is one method that has worked for me in the past.