add 'replace' option to overwrite existing process.env keys

[guymguym]

hi
the code ignores existing keys if already found in the process.env and does not overwrite them.
for some cases that works fine, however in some cases we keep a .env file which is expected to overwrite existing environment variables even if already present.
so I think an option would be helpful like that -
load({replace: true}) or load({force: true})
what do you think?
would love to submit a PR if that makes sense.
thanks!

[maxbeatty]

Can you expand on your use case for needing to overwrite existing environment variables?

The current logic is based on the assumption that you have control over the environment you're running your code in meaning you should be able to control the order in which your environment variables are assigned. You can load multiple files to emulate overwriting.

.env.override

NODE_ENV=override

.env

NODE_ENV=example

index.js

const assert = require('assert')
const dotenv = require('dotenv')
dotenv.load({ path: '.env.override' })
dotenv.load()
assert.equal(process.env.NODE_ENV, 'override')

If .env.override is missing in some environments, it'll safely fail and move on.

[guymguym]

Hi @maxbeatty Thanks for the fast reply.

In my case the environment is coming from the parent process (currently it is supervisord), and I simply want to override any inherited environment with my .env. We actually encountered a case when the application env got merged into parent and later was not able to be modified using changes of .env.

So the case is that the .env file represents an overriding environment over the parent's env, and I also want it to be used regardless of the parent that spawned it.

Anyhow, my suggestion is indeed a tiny addition, that may or may not be useful to anyone else, but it's not very disturbing, right?

Many thanks!
Guy

[guymguym]

and according to your terminology, this option is best described as load({override: true}) which works well for me.

[maxbeatty]

Sorry, I'm still not totally understanding the use case. I get you want process.env[key] = val || process.env[key] more or less, but it would be helpful to understand what exactly you're trying to override. Is it a database password? API key? Feature flag? Something else entirely?

Are there certain environments where this is more useful than others? Testing environments like CI can sometimes be hard to configure thus needing more options.

Some quick pseudo code or an example repo would really help 😸

[guymguym]

one specific case is enabling/disabling a specific service that we run internally.
another is listening ports.
but these are just examples.
the basic thing is that we have a .env that needs to override the parent env.
makes sense?

[maxbeatty]

the basic thing is that we have a .env that needs to override the parent env

Instead of adding an additional configuration option, I think a better approach is to assign your environment variables in the proper order which it sounds like you have control over. If you're dead set on overriding process.env entries based on a specific .env file at a specific point in time, you can do something like this:

const fs = require('fs')
const dotenv = require('dotenv')
const envConfig = dotenv.parse(fs.readFileSync('.env.override'))
for (var k in envConfig) {
  process.env[k] = envConfig[k]
}

[guymguym]

can you explain why is that any better?
clearly i can just write the dotenv module myself, and do whatever i need, but isn't that the purpose of this project?

[huttj]

Just wanted to chime in here and say that dotenv not overwriting my existing environment variables (which is what I expected it to do, prior to reading the FAQs), caused a fair amount of confusion for me.

I am running an app in an environment that I don't manage, and that environment has a USERNAME variable already specified. Because of this, my app did not work, as it was using the wrong username.

I would prefer to not worry about what variables exist in the environment, and just to specify what I want them to be, for my app.

My workaround is to just prefix my variables. Not ideal, but it works to minimize the chance of collisions.

[tranvansang]

the basic thing is that we have a .env that needs to override the parent env

Instead of adding an additional configuration option, I think a better approach is to assign your environment variables in the proper order which it sounds like you have control over. If you're dead set on overriding process.env entries based on a specific .env file at a specific point in time, you can do something like this:

const fs = require('fs')
const dotenv = require('dotenv')
const envConfig = dotenv.parse(fs.readFileSync('.env.override'))
for (var k in envConfig) {
  process.env[k] = envConfig[k]
}

Thank you for the snippet.

In my case, I have AWS_SECRET_KEY in .env.

One of our developers has AWS_SECRET_KEY in his PC, which is not overwritten by our app specific .env config. He continuously got permission error due to the incorrect configuration.

After debugging I googled and arrived at this thread. And I was surprised that dotenv does not have this option (in a native way).

I think it does not harm if the package provides a straigtforward option for us to opt-in in such this case.

[sbvijaykumar]

Hi, I have a usecase to support the existence of override option in dotenv.
I have a data staging script, which takes the meta data from my QA Env and move it to Staging Env. So I have written a node js script to load the data from QA database(DB connection url is there in .env.qa file) and do some checks and move it to Staging database(DB connection url is there in .env.staging file). So to do this I have to load different env files.

Please suggest how to go about this. Instead of manually setting the key/value in process.env, we can write it without dotenv.

I think dotenv should have override option, people use it based on their use case.