镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

process.loadEnvFile() does not override existing environment variables #63027

Description

@shikanime

Version

v24.14.0

Platform

Darwin telsha 25.4.0 Darwin Kernel Version 25.4.0: Thu Mar 19 19:31:09 PDT 2026; root:xnu-12377.101.15~1/RELEASE_ARM64_T8132 arm64

Subsystem

No response

What steps will reproduce the bug?

  1. Create two files: .env with KEY=original and .env.test with KEY=override.
  2. Run the following in the Node.js REPL:
// Load the first file
process.loadEnvFile(".env");
console.log(process.env.KEY); // 'original'

// Attempt to load the second file to override the value
process.loadEnvFile(".env.test");
console.log(process.env.KEY); // Still 'original'

Mitigation:

import { parseEnv } from 'node:util';
import { readFileSync } from 'node:fs';

// This forces the override
const integConfigs = parseEnv(readFileSync("apps/server/.env.integ", "utf8"));
Object.assign(process.env, integConfigs);

How often does it reproduce? Is there a required condition?

It reproduces 100% of the time. The condition is that a variable must already exist in process.env (either from the shell or a previous loadEnvFile call) for the "bug" to be visible.

What is the expected behavior? Why is that the expected behavior?

While the default behavior of not overriding is standard for dotenv, there is currently no programmatic way (via options) to force an override using process.loadEnvFile().

At the very least, subsequent calls to process.loadEnvFile() should support an { override: true } option to allow developers to switch environment contexts (e.g., switching to an integration/test config) without manually parsing files via util.parseEnv.

What do you see instead?

The variable remains locked to the first value it was assigned. Subsequent calls to loadEnvFile for the same key are silently ignored for that specific key.

Additional information

Most modern environment loaders (like the dotenv npm package) provide an override flag. Without this, process.loadEnvFile is significantly less useful for complex test runners or mono-repos where multiple .env files must be composed or swapped during a single process lifetime.

Activity

  1. Han5991 commented on Apr 29, 2026

    @Han5991
    Contributor

    This is intentional — established as the documented contract in #49424 (Sep 2023). Before that, .env did override env vars, but it contradicted the docs: "the value from the environment takes precedence".

    The opt-in { override: true } option you're asking for is already implemented in #52531 (3 approvals, currently stalled with merge conflicts) — effectively a duplicate.

    Refs: #49148 (umbrella tracker)

  2. marco-ippolito commented on Apr 29, 2026

    @marco-ippolito
    Member

    marking as feature request since the current behavior is by design

  3. shikanime commented on Apr 30, 2026

    @shikanime
    Author

    Got it. One thing I noticed is that the behaviour is slightly different when using the CLI. For example, using the command line arguments --env-file=.env and --env-file=.env.integ will override the previous settings. I believed that the implementation and behaviour were the same.

  4. AugustinMauroy commented on May 7, 2026

    @AugustinMauroy
    Member

    +1 for the override option

  5. added
    dotenvIssues and PRs related to .env file parsing.
    on Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    dotenvIssues and PRs related to .env file parsing.feature requestIssues requesting new Node.js features.

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions