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

Support .env, .env.local, .env.<environment> practice #37

Closed
plashenkov opened this issue Jun 22, 2020 · 11 comments
Closed

Support .env, .env.local, .env.<environment> practice #37

plashenkov opened this issue Jun 22, 2020 · 11 comments

Comments

@plashenkov
Copy link
Contributor

plashenkov commented Jun 22, 2020

Hey!

Thanks for this awesome lib!

It would be nice if dotenv-cli could read variables from multiple .env files. There is a common approach to use .env and .env.local, and maybe .env.<environment> (.env.production, .env.development, etc.) schema.

Here are the examples:

It's a common and nice practice since you can use common defaults in an .env file and then override them in a machine-specific .env.local. Usually you commit .env to a git repository and do not commit .env.local (secrets go there).

Currently we can use -e envfile many times, but it would be nice to have, for example, a special argument to activate this schema:

dotenv --cascade -- <command with arguments>
# or different argument name of course
@plashenkov plashenkov changed the title Support Support .env, .env.local, .env.<environment> practice Jun 22, 2020
@entropitor
Copy link
Owner

@plashenkov so basically you would want a flag like --cascade or --local that is basically equivalent to -e .env -e .env.local? Or how would it work exactly?

@plashenkov
Copy link
Contributor Author

Yep, usually these files participate in this flow:

.env.<environment>.local, .env.<environment>, .env.local, .env

Files on the left have more priority than files on the right. I.e. if .env.local and .env have the same variable, the value from .env.local has to be taken.

And real environment variables always win over env vars created by any of the .env files:

SOMEVAR=somevalue dotenv --cascade -- <command with arguments>

SOMEVAR=somevalue should take the top precedence.

@plashenkov
Copy link
Contributor Author

plashenkov commented Jun 22, 2020

.env.<environment>.local, .env.<environment>, .env.local, .env

Where <environment> = 'production', 'development', 'test', i.e. NODE_ENV

@entropitor
Copy link
Owner

@plashenkov the problem is that we should probably not read out NODE_ENV as there is also RAILS_ENV etc. and that would explode quickly (and what if both NODE_ENV and RAILS_ENV are defined...)

What could work is something like --cascade which defaults to development and then --cascade=production to change the environment. WDYT?

@plashenkov
Copy link
Contributor Author

I think that's great. Probably we shouldn't use 'development' by default since sometimes 'dev' can be used (in Symfony for example). Maybe if omitted we should just ignore .env.<environment> and .env.<environment>.local files.

@entropitor
Copy link
Owner

@plashenkov That makes sense! You want to take a stab at it?

@plashenkov
Copy link
Contributor Author

Sorry I'm not so fluent in English. :) What does "want to take a stab at it" mean?

@entropitor
Copy link
Owner

Ah sorry, I meant to ask if you want to try implementing this feature and make a pull request?

@plashenkov
Copy link
Contributor Author

Yep, I think I'll try. Nearest days.

@plashenkov
Copy link
Contributor Author

Ok, done. Is it okay for you to update the help text and readme?

@plashenkov
Copy link
Contributor Author

Is it okay to use -c instead of --cascade?

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