Feature proposal: use/don't-override already set environment variables

[wachunei]

Hello,

I was having an issue when testing my app in a cloud service, it was failing because I was not versioning any .env files (cause I was being stupid and just had .env and .env.production instead of .env, .env.development, .env.production).

Anyway, I figured out you can set up environment variables for your cloud environment, of course these were not being used since the plugin only looks for .env.* and throws when importing something that has not been set.

On the other hand, from dotenv rules:

What happens to environment variables that were already set?
We will never modify any environment variables that have already been set. In particular, if there is a variable in your .env file which collides with one that already exists in your environment, then that variable will be skipped.

So, what do you think about, before checking presence of the variable in the dotEnv config result, check if process.env already has a variable set for that name and replace it with that instead of the .env file, replicating the behavior of dotenv package.

edit: I guess this is related to with #32

[ThatGuySam]

I found a temporary solution:
Create and commit a .env.example file that has any env variables required for testing(also you could do .env.test)

In your testing environment run this command first or at least before you npm install
cp .env.example .env

This creates a new .env file with the exact contents of .env.example

You still shouldn't store secret keys your .env.example file but with this you can store things like api urls, endpoints, public keys, and anything else that's okay being public and needed for testing.

[nickarora]

In my opinion, this should not be considered a feature request -- it should be considered a bug. Its contrary to expected behavior from dotenv