-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.env in source control ? #2560
Comments
Per #1344, we are strictly supporting environment files which fall under the official specification. There has been discussion before but I'm pretty sure we're not going to allow manually setting |
I'll close this as a duplicate (proposal) of #790, thanks! |
ok thanks for the reply, hadn't seen #1344. I got it working by using - .env.development.local // development
- .env // staging
- .env.production // production Then when I build with Jenkins my staging release, I delete the production config wit |
Hey guys, i'm late to the party but i resolved this with a lib called env-cmd, who works like dotenv but with files. And i builded my app with the following: |
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:
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
Cheers.
The text was updated successfully, but these errors were encountered: