Description
I am wondering why you recommend to put environment variable into source control in your README.
dotenv says:
"We strongly recommend against committing your .env file to version control."
And from the twelve-factor app:
"Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally;"
https://12factor.net/config
Isn't it the whole purpose of having separate .env files/environment to not put in source control secret keys?
thanks.
[EDIT]
It is true that there is nothing like "secret' in frontend apps :) So I understand that being in source control or not should not bring any security issue.
What I am tying to achieve is to have .env file in a "staging" environment and being able to build with that environment by running:
NODE_ENV=staging npm build
I read in the docs that we cannot manually override the NODE_ENV. I understand the "production build" part but why not just set the build to a "production one" internally (uglify, minify, tree shaking...) for all the environment that are not "development" or "test". That way we could have different config/environment
- .env.staging
- .env.acceptance
- ...
Cheers.