Skip to content

.env in source control ? #2560

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
sebelga opened this issue Jun 18, 2017 · 4 comments
Closed

.env in source control ? #2560

sebelga opened this issue Jun 18, 2017 · 4 comments

Comments

@sebelga
Copy link

sebelga commented Jun 18, 2017

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.

@Timer
Copy link
Contributor

Timer commented Jun 18, 2017

.env files for front-end code should be checked in, because as you said, it contains no secrets. Additionally, these .env files affect build-time, not runtime behavior.

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 NODE_ENV anytime soon.
If you'd like this level of granularity and feel comfortable with these configs, please eject and configure them yourself.

@Timer
Copy link
Contributor

Timer commented Jun 18, 2017

I'll close this as a duplicate (proposal) of #790, thanks!

@Timer Timer closed this as completed Jun 18, 2017
@sebelga
Copy link
Author

sebelga commented Jun 18, 2017

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 rm -f .env.production before the build.
Still didn't get what was wrong in having different .env file per environment but it's ok :)

@bruno-vinicius
Copy link

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:
env-cmd .env.custom npm run build.

@lock lock bot locked and limited conversation to collaborators Jan 19, 2019
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Projects
None yet
Development

No branches or pull requests

3 participants