React Best Practices
How to manage the settings that are different from local vs dev vs prod; such as api urls, resources, other parameters...
React Best Practices
How to manage the settings that are different from local vs dev vs prod; such as api urls, resources, other parameters...
For further actions, you may consider blocking this person and/or reporting abuse
Sebastien Lorber -
Sonay Kara -
Riyon Sebastian -
Habib Hinn -
Top comments (4)
I would keep
.env
or other local configuration files out of version control. Add those files to.gitignore
(in case you're using git) so they cannot ever be accidentally committed. Create a template with comments and explanations for your config file which can be customized by each developer working on the project (e.g..env.template
). That template file can be added to version control.I would use a CI server such as Jenkins for building and deploying environment specific versions of your project. There are plenty of plugins and features that allow you to take full control over the build process.
One of those features is storing local configuration files such as
.env
files right in your CI server's database. You can add staging and production build configuration files to your CI server, and set up a build script that:This has the following advantages:
Minor downside:
Like you, I am currently searching for this answer.
I have used some of the suggested solutions already. I created different .env files. This still requires your code to have different build branches based on target environment. The built-for-production code is not portable between staging and production environments, for example. You would have to build again for staging.
What I wish for is something like config with 12-factor apps. I can build a backend service that can run in dev or staging or production without modification. Because the configuration comes from the running machine's environment vars instead of something that gets packaged into the app on build.
The only way I can think of to accomplish something like this with JS is to fetch a config file as the app's first action. It would need to call a separate configuration service that returns different configs depending on who is asking (e.g. Origin header). That feels like it misses the point a bit, but is probably closest to creating environment-portable apps.
I have been using .env file for environment specific configurations.