Skip to content
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

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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants