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

Use silent by default #111

Closed
timwis opened this issue Dec 2, 2015 · 2 comments
Closed

Use silent by default #111

timwis opened this issue Dec 2, 2015 · 2 comments

Comments

@timwis
Copy link

timwis commented Dec 2, 2015

Hey guys, I love the dotenv concept and use it in JS and Python. I'd like to suggest, though, that silent be true by default. I use .env files locally, but when I deploy somewhere like heroku, I don't (and can't) use them - I use actual environment variables via their config settings. It seems like a tool like dotenv should check if there is a .env file, and use that above all else, but gracefully fall back on actual environment variables if it isn't there. I can't think of a scenario where I'd want it to throw an error instead of looking for proper environment variables. And if there is a scenario, it certainly feels less common and thus should be explicitly set. Thoughts?

@maxbeatty
Copy link
Contributor

a tool like dotenv should check if there is a .env file, and use that above all else

We respect the current process.env over .env to allow cascading assignment in the opposite direction you're thinking of (process.env then .env then another .env etc.)

gracefully fall back on actual environment variables if it isn't there

process.env is populated by node before .env is loaded or attempted to be loaded so your actual environment variables always take precedence.

I'd want it to throw an error instead of looking for proper environment variables

Node populates process.env with "proper environment variables." We catch the error that is thrown when the .env file is missing and log it which is helpful for people getting started and understanding what may not be working. That's more important to me than prettier startup logs.

@timwis
Copy link
Author

timwis commented Dec 4, 2015

Okay thanks for the background, Max

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants