main.js is mentioning "Allows configuration before loading .env and .env.$NODE_ENV".
I can't get per-environment config to work. Ex. starting my node app with NODE_ENV=test doesn't seems to load .env.test.
I'm trying to override some defaults in .env by using .env.test for some config that need to apply only when running tests ex. setting a different database when NODE_ENV is "test".
Seems support for that was dropped when doing the 1.0.0 overhaul. Reverting to 0.5.1 works.
If you want to stay on 1.x you can instead do something like the following:
var envPath = '/path/to/.env';
if (process.env.NODE_ENV === 'test') {
envPath = '/path/to/.env.test';
}
require('dotenv').config({path: envPath});
@motdotla that wont work, before 1.x we used to be able to "override" by providing .env along side a .env.test. For example, setting different database options in .env.test for when running with NODE_ENV=test, while still using all the other settings from .env.
What you recommend would simply load .env.test instead of .env, not "override" the values from .env with those in .env.test.
@motdotla @maxbeatty do you mind keeping this issue open until this is fixed? This is a regression in 1.x. Or do you have no plan for supporting this anymore and officially dropping this from 1.x? Are you open to pull requests, etc.? Please reopen the issue.
Thanks
@siboulet I don't think we are going to supporting this anymore. I know we are, for sure, not adding back .env.${NODE_ENV} support and it looks like we are not adding override support https://github.com/motdotla/dotenv/pull/72. I have to say I was open to having override support was not a huge fan of the implementation in this PR. I would say if you can make a compelling enough argument for it you might be able to convince @maxbeatty and @motdotla
This is not a regression. We follow semver for versioning, and 1.x.x was a MAJOR release with breaking changes. We purposely removed the ability for this poor practice. If you are overriding variables, you are not treating your environments as unique instances. For example, your database password for staging should be different than production. If you have values that are shared across deploys, they're either insecure or may not be environment variables to begin with.
This module respects process.env over new values being set so if you _really_ need to load two configs you can:
var dotenv = require('dotenv');
dotenv.config({path: '.env.test'}); // most important values
dotenv.config({path: '.env'}); // fill in the gaps
Since we've covered this topic multiple times, I'm going to add it to the FAQ
Thanks for the thorough explanation. This make sense now. And for anyone that _really_ needs to have the override feature and 1.x, she can always use the successive calls to dotenv.config() as mentioned in the comment above. That works for me.
Also might worth removing the mention of .env.$NODE_ENV here to remove any confusion: https://github.com/motdotla/dotenv/blob/master/lib/main.js#L7
Thanks
I believe comment
Allows configuration before loading .env and .env.$NODE_ENV
Should be changed to account for this breaking change - tried to make .env.test work for some time until reading more code & seeing it's not supported