Open wachunei opened 6 years ago
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.
In my opinion, this should not be considered a feature request -- it should be considered a bug. Its contrary to expected behavior from dotenv
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: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