Support .env, .env.local, .env.<environment> practice about dotenv-cli HOT 11 CLOSED

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

from dotenv-cli.

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.

from dotenv-cli.

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

from dotenv-cli.

@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?

from dotenv-cli.

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

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

from dotenv-cli.

@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?

from dotenv-cli.

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.

from dotenv-cli.

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

from dotenv-cli.

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

from dotenv-cli.

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

from dotenv-cli.

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

from dotenv-cli.