Question: Possible to load multiple .env files into the shell?

[basickarl]

Question: Is it possible to load multiple .env files into the shell?

npx dotenv-extended --path=first.env dotenv-extended --path=second.env node herro.js

Or something like:

npx dotenv-extended --path=first.env,second.env node herro.js

[keithmorris]

@basickarl can you give me a use case for this? This would require a bit if refactoring to support and I'm not sure how often this would be used.

[dmitryvmin]

One use case would be if your configs are env specific - "qa", "prod", etc.

Something like would be useful:

env.qa.defaults + .env.qa
env.prod.defaults + env.prod

[keithmorris]

@dmitryvmin It seems that this can already be accomplished with the dotenv-extended command:

e.g. for QA:
dotenv-extended --path=/path/to/.env.qa --defaults=/path/to/.env.qa.defaults --errorOnMissing=true ./myshellscript.sh --whatever-flags-my-script-takes

Then for prod:
dotenv-extended --path=/path/to/.env.prod --defaults=/path/to/.env.prod.defaults --errorOnMissing=true ./myshellscript.sh --whatever-flags-my-script-takes

Am I misunderstanding?

[mvastola]

I was about to post this same feature request. The idea would be to allow for multiple layers of defaults/settings, as provided by dotenv-flow (which is fairly popular) as well as similar modules.

These other modules, however, aren't easily made compatible with dotenv-extended, however, without allowing the overriding of values already in the environment. (Or otherwise by saving the original environment and re-applying it after the changes in this module.)

Implementing this feature a really simple change as well. The vast majority of the change is simply updating src/index.js to say

let envFiles = [];
[ options.defaults, options.path ].forEach(files => {
  if (!files || files.length === 0) return;
  if (!Array.isArray(files)) files = [ files ];
  envFiles.push(...files);
});
let configData = files.reduce((accumulator, file) => {
  let fileData = loadEnvironmentFile(file, options.encoding, options.silent);
  return { ...accumulator, ...fileData };
});

Beyond that, pretty much only CLI argument parsing would need to be tweaked, and documentation would need to be updated.

[goatandsheep]

@mvastola so like this? #50

[basickarl]

@goatandsheep You perhaps need to update the tests?

[mvastola]

@goatandsheep , it looks like you copied my code verbatim (and my code still makes sense to me, surprisingly), so I'm going to guess 'yes', but I honestly barely remember this request, hah.

[keithmorris]

Implemented and documented support for layered dotenv files for both path and defaults. This will be in the next release.

What’s now supported

• path and defaults accept:
  • a single string path
  • an array of paths (layered)
  • comma-separated paths via env vars:
    • DOTENV_CONFIG_PATH
    • DOTENV_CONFIG_DEFAULTS

Merge behavior

• Deterministic precedence:
  1. defaults layers in order (last wins)
  2. path layers in order (last wins)
• This keeps existing behavior intact while enabling multi-file composition.

Validation and docs

• Added explicit unit/functional tests for:
  • layered defaults precedence
  • layered path precedence
  • combined defaults+path layering
  • comma-separated DOTENV_CONFIG_* layered config
• Updated README with detailed examples and precedence documentation.
• Full test suite and coverage pass (100%).