You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Any values set in .env trump those of the environment specific ones (e.g. .env.staging). Surely it should be the other way around, no? .env should be the default settings and the environment specific .env files should be the overriding ones. This way the environment specific env file values can be restricted to overriding the common, default values. In the current situation if for example there are 30 environment values and 20 of them are being overridden in some environment specific .env files you have to remove those 20 values from the default .env file and explicitly set them in all of the specific .env files. Meaning that if you decide that the default value of one of those environment values should be changed, you have to search through multiple environment specific .env files to change it.
I understand it should be possible to override any NODE_ENV values from the CLI, which is why I'd propose the following resolution mechanism:
CLI > .env.<specific> > .env
If you guys agree I'll issue a PR with the modifications and updated tests.
The text was updated successfully, but these errors were encountered:
Aaargh. Never mind. the project I was tinkering with apparently did a double call to dotenv.load for some reason. I was misled by the process.env[key] = process.env[key] || value; line, and thought a value set in .env would immediately be stored in process.env, now I realise it's not.
Sorry for bothering you guys!
ATM the way overrides work seem backwards to me.
Any values set in
.env
trump those of the environment specific ones (e.g..env.staging
). Surely it should be the other way around, no?.env
should be the default settings and the environment specific.env
files should be the overriding ones. This way the environment specific env file values can be restricted to overriding the common, default values. In the current situation if for example there are 30 environment values and 20 of them are being overridden in some environment specific.env
files you have to remove those 20 values from the default.env
file and explicitly set them in all of the specific.env
files. Meaning that if you decide that the default value of one of those environment values should be changed, you have to search through multiple environment specific.env
files to change it.I understand it should be possible to override any NODE_ENV values from the CLI, which is why I'd propose the following resolution mechanism:
CLI >
.env.<specific>
>.env
If you guys agree I'll issue a PR with the modifications and updated tests.
The text was updated successfully, but these errors were encountered: