Skip to content
This repository has been archived by the owner on Jul 8, 2020. It is now read-only.

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

Open
wachunei opened this issue Jan 17, 2018 · 2 comments · May be fixed by #63
Open

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

wachunei opened this issue Jan 17, 2018 · 2 comments · May be fixed by #63

Comments

@wachunei
Copy link
Contributor

wachunei commented Jan 17, 2018

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
Copy link

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
Copy link

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

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

Successfully merging a pull request may close this issue.

3 participants