When using dotenv -- <some_command>, if some command has colored output, dotenv will remove it.

I guess that the issue exists because of cross-spawn that is used to spawn the sub-process. I'm wondering if in 2023 node:child_process still has issues with windows (which is, I believe, the reason you used cross-spawn in the first place.

This works

npx dotenv -e env ava -w

This doesn't

npx dotenv ava -v

/backend/node_modules/dotenv-cli/cli.js:62
    variables.push(...argv.v.map(validateCmdVariable))
                             ^

TypeError: argv.v.map is not a function
    at Object.<anonymous> (/Users/kevin/Development/JavaScript/scrolli/backend/node_modules/dotenv-cli/cli.js:62:30)
    at Module._compile (node:internal/modules/cjs/loader:1095:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1147:10)
    at Module.load (node:internal/modules/cjs/loader:975:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

When I try to run npx dotenv I get the following error:

> npx dotenv
npm ERR! could not determine executable to run

Versions

> node -v
v18.16.0

> npm -v
9.5.1

Full Debug Log

0 verbose cli /Users/coder/.asdf/installs/nodejs/18.16.0/bin/node /Users/coder/.asdf/installs/nodejs/18.16.0/lib/node_modules/npm/bin/npm-cli.js
1 info using [email protected]
2 info using [email protected]
3 timing npm:load:whichnode Completed in 0ms
4 timing config:load:defaults Completed in 1ms
5 timing config:load:file:/Users/coder/.asdf/installs/nodejs/18.16.0/lib/node_modules/npm/npmrc Completed in 0ms
6 timing config:load:builtin Completed in 1ms
7 timing config:load:cli Completed in 0ms
8 timing config:load:env Completed in 0ms
9 timing config:load:file:/Users/coder/projects/project-name/ssr/.npmrc Completed in 0ms
10 timing config:load:project Completed in 1ms
11 timing config:load:file:/Users/coder/.npmrc Completed in 0ms
12 timing config:load:user Completed in 0ms
13 timing config:load:file:/Users/coder/.asdf/installs/nodejs/18.16.0/etc/npmrc Completed in 0ms
14 timing config:load:global Completed in 0ms
15 timing config:load:setEnvs Completed in 1ms
16 timing config:load Completed in 4ms
17 timing npm:load:configload Completed in 4ms
18 timing npm:load:mkdirpcache Completed in 0ms
19 timing npm:load:mkdirplogs Completed in 0ms
20 verbose title npm exec dotenv
21 verbose argv "exec" "--" "dotenv"
22 timing npm:load:setTitle Completed in 6ms
23 timing config:load:flatten Completed in 1ms
24 timing npm:load:display Completed in 1ms
25 verbose logfile logs-max:10 dir:/Users/coder/.npm/_logs/2023-09-05T21_57_41_214Z-
26 verbose logfile /Users/coder/.npm/_logs/2023-09-05T21_57_41_214Z-debug-0.log
27 timing npm:load:logFile Completed in 3ms
28 timing npm:load:timers Completed in 0ms
29 timing npm:load:configScope Completed in 0ms
30 timing npm:load Completed in 14ms
31 silly logfile start cleaning logs, removing 2 files
32 silly logfile done cleaning log files
33 timing arborist:ctor Completed in 0ms
34 timing arborist:ctor Completed in 0ms
35 timing command:exec Completed in 211ms
36 verbose stack Error: could not determine executable to run
36 verbose stack     at getBinFromManifest (/Users/coder/.asdf/installs/nodejs/18.16.0/lib/node_modules/npm/node_modules/libnpmexec/lib/get-bin-from-manifest.js:17:23)
36 verbose stack     at exec (/Users/coder/.asdf/installs/nodejs/18.16.0/lib/node_modules/npm/node_modules/libnpmexec/lib/index.js:185:15)
36 verbose stack     at async module.exports (/Users/coder/.asdf/installs/nodejs/18.16.0/lib/node_modules/npm/lib/cli.js:134:5)
37 verbose pkgid [email protected]
38 verbose cwd /Users/coder/projects/project-name/ssr
39 verbose Darwin 22.3.0
40 verbose node v18.16.0
41 verbose npm  v9.5.1
42 error could not determine executable to run
43 verbose exit 1
44 timing npm Completed in 234ms
45 verbose code 1
46 error A complete log of this run can be found in:
46 error     /Users/coder/.npm/_logs/2023-09-05T21_57_41_214Z-debug-0.log

I am trying to run dotenv on my local project which has a .env file in the root but I'm getting this error

$ dotenv -e .env
child_process.js:389
    throw new TypeError('"file" argument must be a non-empty string');
    ^

TypeError: "file" argument must be a non-empty string
    at normalizeSpawnArguments (child_process.js:389:11)
    at Object.exports.spawn (child_process.js:502:38)
    at spawn (/Users/localuser/.config/yarn/global/node_modules/dotenv-cli/node_modules/cross-spawn/index.js:17:18)
    at Object.<anonymous> (/Users/localuser/.config/yarn/global/node_modules/dotenv-cli/cli.js:27:1)
    at Module._compile (module.js:653:30)
    at Object.Module._extensions..js (module.js:664:10)
    at Module.load (module.js:566:32)
    at tryModuleLoad (module.js:506:12)
    at Function.Module._load (module.js:498:3)
    at Function.Module.runMain (module.js:694:10)

For example: dotenv mvn exec:java -Dexec.args="-g -f" does not pass those -g -f args into the Java method, whilst mvn exec:java -Dexec.args="-g -f" works in this case.

When Lerna is launched like so

$ dotenv lerna run start --parallel

> [email protected] start /Users/dis/Sites/xxx
> dotenv lerna run start --parallel

lerna notice cli v3.8.4
lerna info Executing command in 2 packages: "npm run start"

And the no output although all scripts are running normally.

When dotenv-cli is added to each package and used there it works fine.

Resurrecting #46, it would be great to have an option to ignore environment vars and set the variables from a file. According to the last comment in that issue, the override feature is now available in dotenv. Ideally a -o/--override flag would enable this functionality.

Repro

Have the following files:

.env:

LANG=en-US
GENERAL=works

hello.js:

console.log('LANG', process.env.LANG);
console.log('GENERAL', process.env.GENERAL);

And run

node_modules/.bin/dotenv node hello.js

Expected result

LANG en-US
GENERAL works

Actual result

LANG en_AU.UTF-8
GENERAL works

Notice that LANG was not loaded correctly.

More

I've narrowed it down to the call to dotenvExpand here :

If I log the following:

// your code
paths.forEach(function (env) {
  dotenvExpand(dotenv.config({ path: path.resolve(env) }))
})

// my log statements
console.log('FROM loaded', dotenv.config({ path: path.resolve('.env') }));
console.log('FROM expanded', dotenvExpand(dotenv.config({ path: path.resolve('.env') })));
console.log('VALUES:', 'LANG',  process.env.LANG, 'GENERAL', process.env.GENERAL);

I get (notice how LANG is changed in expanded) :

FROM loaded { parsed: { LANG: 'en-US', GENERAL: 'works' } }
FROM expanded { parsed: { LANG: 'en_AU.UTF-8', GENERAL: 'works' } }
VALUES: LANG en_AU.UTF-8 GENERAL works

Just so I don't have to open the docs to find out what the flags are

Sample .env file that uses Command Substitution:
https://github.com/bkeepers/dotenv#command-substitution

postgresql://$(whoami):@localhost:5432/my_db?schema=public

$(whoami) is not resolved

I recently came across this package and it's excellent for my use case. However, because the documentation recommends:

dotenv -e .env2 <command with arguments>

I assumed I could simply run:

dotenv -e ../../../.env -- docker compose up -d

You can imagine my confusion to find that the "-d" flag was being ignored. I very nearly moved onto another package due to this issue.

To avoid similar foot guns, I would suggest updating the documentation to recommend:

dotenv -- <command with arguments>
dotenv -e .env2 -- <command with arguments>

Or to very clearly call out the foot guns when omitting "--" separator.

dotenv-expand allows developers to reference process.env variables inside their .env files.

For example:

IP=127.0.0.1
PORT=1234
APP_URL=http://${IP}:${PORT}

Using the above example .env file, process.env.APP_URL would be http://127.0.0.1:1234.

Would you be open to exporting the variables for use after running the cli?

My use-case is, In package.json scripts, I would like to reference the variables in the .env file.

Ideally, dotenv echo $VAR_NAME would work, but $VAR_NAME is evaluated too early so I have to do something like echo $(dotenv -p $VAR_NAME) which is very verbose.

I was thinking we could support dotenv; echo $VAR_NAME or maybe a new flag if you'd prefer?

npm audit reports several issues with the versions of packages being used.

This does not work when running npm start:

"scripts": {
    "start": "dotenv next -- start -p $PORT"
}

The exiting error being:

TypeError [ERR_INVALID_OPT_VALUE]: The value "{ port: true }" is invalid for option "options"
    at Server.listen (net.js:1450:9)
    …

But this does work:

"scripts": {
    "start": "dotenv npm run start:next",
    "start:next": "next start -p $PORT"
}

Unfortunately the Next.js CLI does not respect a PORT env variable, only the CLI -p arg.

What's change that leaded to a major version bump?
Shouldn't there be a git tag of the release?

This feature is similar to what cross-emv does.
Sometimes, I want to import variables both from the file and from the command line.
It would be nice if dotenv-cli would be the multiplatform tool to do that.

Proposal

Add new option to load variables from command line. For example -v:

dotenv -e ./config/.env -e ./config/.env.dev -v DB_HOST=localhost -v DB_USER=root -v DB_PASS=root -- node ./scripts/something.js

or maybe just use of single option

dotenv -e ./config/.env -e ./config/.env.dev -v DB_HOST=localhost DB_USER=root DB_PASS=root -- node ./scripts/something.js

dotenv -e ./config/.env -e ./config/.env.dev -v DB_HOST=localhost;DB_USER=root;DB_PASS=root -- node ./scripts/something.js

(Just suggestion, I would prefer most the first way)

Right now the solution would need to use both cross-env and dotenv-cli

cross-env DB_HOST=localhost DB_USER=root DB_PASS=root  dotenv -e ./config/.env -e ./config/.env.dev -- node ./scripts/something.js

When using cascading env variables, you might end up with a lot of .env files. It is then common to group the .env files in a folder. Would it be possible to add a flag for specifying where dotenv should look for .env files? I suggest -d <dir>. For consistency, I think it should also work without -c, though that is probably the main use case.

# Load vars/.env (-d without -e or -c)
dotenv -d vars <cmd>

# Load vars/.env2 (-d combined with -e)
dotenv -d vars -e .env2 <cmd>

# Load env/.env.local and env/.env (-d combined with -c)
dotenv -d env -c <cmd>

Hello,

the override system is now available is dotenv (https://github.com/motdotla/dotenv/blob/master/CHANGELOG.md#1410-2022-01-17)

It would be nice to get it in dotenv-cli

Have a nice day!

The override option introduced in #87 by @jfairley conflicts with the cascade option when both are used together.

Example

.env

MY_NAME=Bob

.env.local

MY_NAME=Joe

Command

> dotenv -c -- bash -c 'echo $MY_NAME'
Joe
> dotenv -co -- bash -c 'echo $MY_NAME'
Bob

I would expect Joe from .env.local to override Bob from .env based on how cascade works, but when the override option is present Bob prevails because .env is processed last (see here and here).

dotenv should be a peer dependency to allow using latest dotenv versions

I just saw the package is updated to v4.0.0, but I can't find any CHANGELOG to check out the changes.

Would you be so kind to provide us with a decent CHANGELOG please? 🙂

Thanks for all your hard work @entropitor! 🙂

Version 2.0.0 of this package was recently released, but I can't find any changelog. Usually a major version bump means backwards-incompatible changes -- what has changed?

Hi there, thanks for dotenv-cli!

The dotenv version in dependencies is pretty old - ^8.1.0, and the latest version is 16.0.0. Would you be open to upgrading this?

I have the following script in my package.json:
"start:docker": "dotenv -- docker compose -f docker/docker-compose.yml up"

When I exit out of this process - I type ctrl+c and it partially exits out but doesn't completely exit out. How can I get it to completely exit out when I type ctrl+c?

actual behaviour (hangs -> have to hit ctrl + c AGAIN for it to fully exit):

expected behaviour (doesn't hang -> do NOT have to hit ctrl + c AGAIN for it to fully exit):

I have some scripts I am chaining with this one so it presents an issue (note when I don't use dotenv, I do not experience the above issue)

I've just started to use dotenv-cli with cross-var to be able to use .env variables in my package.json. I wrote about it here:
https://medium.com/@arrayknight/how-to-use-env-variables-in-package-json-509b9b663867

I'd like to ask if you think this feature belongs as part of this tool or if I should create something new.

For instance, setting dotenv -v AWS_REGION=eu-west-1 gives you an error of Unexpected argument AWS_REGION=eu-west-1. Expected variable in format variable=value

Description

#37 added support for --casacade, which allows .env, .env.local, .env.<environment>, .env.<environment>.local to override each other in priority. The PR references Create React App, NextJS, and Symfony for the priority order.

However, the priority order in dotenv-cli doesn't match Create React App or NextJS, which I believe is a bug.

NextJS and Create React App both use the following priority, with .env.local values overriding those in .env.development:

1. .env.development.local (Highest)
2. .env.local
3. .env.development
4. .env (Lowest)

(NextJS .env docs here, CRA docs here - note the second section, under "Files on the left have more priority than files on the right")

The CRA source also includes a comment that references bkeepers/dotenv which specifies the same priority in their readme. The NextJS source doesn't include the comment but the implementation is very similar.

Symfony, however, swaps .env.local and .env.development, giving .env.development priority (and looks like this is what @plashenkov modeled the behavior in #37). I think this is actually a bug in Symfony, since the PR that added this behavior references CRA and bkeepers/dotenv, so it looks like they made a mistake in the implementation.

It would be great if dotenv-cli could match Create React App and NextJS, I'm happy to submit a PR for this if you're open to it!

# .env file

ENV_VARIABLE=""

Output

project_route\node_modules\dotenv-expand\lib\main.js:9
    var matches = envValue.match(/(.?\${?(?:[a-zA-Z0-9_]+)?}?)/g) || []
                          ^

TypeError: Cannot read property 'match' of undefined
    at interpolate (project_route\node_modules\dotenv-expand\lib\main.js:9:27)
    at dotenvExpand project_route\node_modules\dotenv-expand\lib\main.js:37:32)
    at project_route\node_modules\dotenv-cli\cli.js:19:3
    at Array.forEach (<anonymous>)
    at Object.<anonymous> (project_route\node_modules\dotenv-cli\cli.js:18:7)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)
error Command failed with exit code 1.

ENV_VARIABLE is being loaded as undefined so envValue = undefined, thus envValue.match throws an error

Hi, thank you for this convenient cli :)

I found a strange behavior. dotenv does not work with direct use of an environment variable.

Let's say my .env file is like the below.

# content of .env
MESSAGE=helloworld

I expect the command below would print "helloworld" on the console.

$ dotenv echo $MESSAGE

However, it doesn't. If an environment variable is directly used on the command after dotenv, then the value is not properly populated.

So, assume I made a file greeting.sh like this.

# content of greeting.sh
echo $MESSAGE

And I changed the command like the below.

$ dotenv ./greeting.sh

And now it works!

This might be quite unexpected to users, isn't it?
I think it'd be better to allow direct use of environment variables after dotenv.
How do you feel?

Thanks.

What happens to environment variables that were already set?
We will never modify any environment variables that have already been set. In particular, if there is a variable in your .env file which collides with one that already exists in your environment, then that variable will be skipped. This behavior allows you to override all .env configurations with a machine-specific environment, although it is not recommended.

Add an option to ignore environment vars and set the variables from a file.

For example a user has NODE_ENV=development set in his system. Jest will fail on that. I want to be able to ignore system vars and set explicitly all variables that I need for my script/command (NODE_ENV=test)

I have the following setup

.npmrc

@fortawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=${FA_TOKEN}

.nvmrc

v10.14.2

.env

FA_TOKEN=XXX

Running

dotenv nvm use

throws

env: node: No such file or directory

Already tried; same result :

dotenv "nvm use"
dotenv -- nvm use
dotenv -- "nvm use"
dotenv nvm use 10.14.2

As example npm --prefix myPath run codegen this works but when i try to use it with dotenv :

dotenv -e .env.dev npm --prefix myPath run codegen I see error :

npm ERR! Missing script: "codegen"
npm ERR!
npm ERR! To see a list of scripts, run:
npm ERR!   npm run

This is just example, the same behaviour with other scripts, does dotenv cli affects somehow path resolving or what is the reason ?

Hello,

First off, thank @entropitor for all of your hard work this awesome tool and I can't wait to start using it!

I've installed dotenv-cli as a dev dependency and created a .env file in my working directory. This is just a test so far so the .env looks like this:

FOO=bar

I can run npx dotenv -p FOO and it prints bar as expected. However, if I run npx dotenv -- echo "$FOO" it prints an empty line. Am I doing something wrong?

Thank you in advance for any help with this! 🤩

Hey!

Thanks for this awesome lib!

It would be nice if dotenv-cli could read variables from multiple .env files. There is a common approach to use .env and .env.local, and maybe .env.<environment> (.env.production, .env.development, etc.) schema.

Here are the examples:

• https://symfony.com/doc/current/configuration.html#overriding-environment-values-via-env-local (Symfony)
• https://nextjs.org/docs/basic-features/environment-variables#default-environment-variables (Next.js)
• https://create-react-app.dev/docs/adding-custom-environment-variables/#what-other-env-files-can-be-used (Create React App)

It's a common and nice practice since you can use common defaults in an .env file and then override them in a machine-specific .env.local. Usually you commit .env to a git repository and do not commit .env.local (secrets go there).

Currently we can use -e envfile many times, but it would be nice to have, for example, a special argument to activate this schema:

dotenv --cascade -- <command with arguments>
# or different argument name of course

I want to load .env into the current shell, but from the docs and code implementation, this feature is missing.

Hi - I like this library a lot, one small request. In build-scripts/any code or documentation that's checked in to source control, our team have a loose convention to always use long options (e.g. --option) rather than short options (e.g. -o) for CLI programs. The idea is that short options are helpful when you're typing and want to move fast, but they're worse if you're reading commands, (say, in an npm script), because they're harder for a newcomer or a code-reviewer to look at and guess what the option does.

So, I think it'd be worthwhile to add long options for these specific options:

  -e <path>           parses the file <path> as a `.env` file and adds the variables to the environment
  -e <path>           multiple -e flags are allowed
  -v <name>=<value>   put variable <name> into environment using value <value>
  -v <name>=<value>   multiple -v flags are allowed
  -p <variable>       print value of <variable> to the console. If you specify this, you do not have to specify a `command`
  -c [environment]    support cascading env variables from `.env`, `.env.<environment>`, `.env.local`, `.env.<environment>.local` files

I'd suggest:

• -e -> --env
• -v -> --variable
• -p -> --print
• -c -> --config

base ❯ npx dotenv-cli -v FOO=bar -- echo $FOO

Which I am expecting to see bar there

If I have a command that ends up running out of memory, it should return code 134 (on Unix, at least). But instead, when used with dotenv-cli, the code is 0. This creates issues in CI environments. For example, a test suite that runs out of memory counts as passing.

To reproduce, create a file test.js with these contents:

const arr = [];

for (let i = 0; i < 10_000_000_000; i++) {
  arr.push(i);
}

And then run this in your terminal:

node --max-old-space-size=1024 test.js
echo $? // 134
node_modules/.bin/dotenv -c test node --max-old-space-size=1024 test.js
echo $? // 0

$ npm run cypress:run:new

> [email protected] cypress:run:new C:\projects\e2e_ssh
> dotenv cross-var cypress run

C:\projects\e2e_ssh\node_modules\dotenv-expand\lib\main.js:20
      const keyParts = parts[2].split(':-')
                                ^

TypeError: Cannot read property 'split' of undefined
    at C:\projects\e2e_ssh\node_modules\dotenv-expand\lib\main.js:20:33
    at Array.reduce (<anonymous>)
    at _interpolate (C:\projects\e2e_ssh\node_modules\dotenv-expand\lib\main.js:6:18)
    at expand (C:\projects\e2e_ssh\node_modules\dotenv-expand\lib\main.js:50:32)
    at C:\projects\e2e_ssh\node_modules\dotenv-cli\cli.js:74:3
    at Array.forEach (<anonymous>)
    at Object.<anonymous> (C:\projects\e2e_ssh\node_modules\dotenv-cli\cli.js:73:7)
    at Module._compile (internal/modules/cjs/loader.js:1072:14)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)
    at Module.load (internal/modules/cjs/loader.js:937:32)

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] cypress:run:new: `dotenv cross-var cypress run`
npm ERR! Exit status 1

node v14
npm v6
dotenv@^16.0.0
[email protected] (with required dotenv-expand@^8.0.1 )

Works ONLY with no such error when I downgrade to [email protected] which under the hood installs dotenv-expand@^5.1.0

Environment

"dotenv-cli": "^5.0.0" (installed as dev dependency, not globally)
Mac OSX 11.1

I'm finding that this tool is incorrectly escaping the $ character when it's referencing a variable in a file that has been run with source.

Steps to Reproduce

Create a new file ~/.envTest file with the following:

export TEST_VAR="default\$default"

Run

$ npx dotenv -e ~/.envTest -- printenv TEST_VAR
default$default
$ source ~/.envTest
$ npx dotenv -e ~/.envTest -- printenv TEST_VAR
default
$ printenv TEST_VAR
default$default

This issue is forcing me to use a separate environment variable file that I don't source in order to allow this to work for my use case that requires the dotenv cli.

I use ${},but it is not useful

I am trying to run it in the same directory where .env are.

$ node -v
v11.9.0

$ dotenv
internal/validators.js:125
    throw new ERR_INVALID_ARG_TYPE(name, 'string', value);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "file" argument must be of type string. Received type undefined
    at validateString (internal/validators.js:125:11)
    at normalizeSpawnArguments (child_process.js:414:3)
    at Object.spawn (child_process.js:553:16)
    at spawn (/Users/silentimp/.nvm/versions/node/v11.9.0/lib/node_modules/dotenv-cli/node_modules/cross-spawn/index.js:17:18)
    at Object.<anonymous> (/Users/silentimp/.nvm/versions/node/v11.9.0/lib/node_modules/dotenv-cli/cli.js:26:1)
    at Module._compile (internal/modules/cjs/loader.js:734:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)
    at Module.load (internal/modules/cjs/loader.js:626:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:566:12)
    at Function.Module._load (internal/modules/cjs/loader.js:558:3)

but it work with --p

$ dotenv -p REACT_APP_LOCALE
it

What has gone wrong?

Just coming in here to say that we would be able to load in the new .env.vault standard if the dotenv version was bumped up to 16.1.4.

Currently we are able to do this by overriding the version resolution in your package.json:

	"resolutions": {
		"dotenv": "^16.1.4"
	},

If you are using .env.vault files you will also be required to set DOTENV_KEY prior to running dotenv-cli like so:

DOTENV_KEY=\"YOUR_KEY\" dotenv -e .env -- $script

Given this will be a new standard I think we should have a flag for passing the key in directly going forward?

Currently library registers only a single binary called dotenv.

I'm using this library in the following manner:

1. i installed it locally: `npm install dotenv-cli --save-dev (i can not install it globally since it's executed on the CI and i have no acces to CI server)
2. in the npm scripts i have the following entry:

scripts: {
      test: "dotenv -c -- node scripts/my-script"
}

the problem is that there is another global command dotenv registered in the system.
In my case this is ruby-gem dotenv

So this npm script uses globally installed ruby dotenv command rather than local dotenv from dotenv-cli package

Solution: dotenv-cli library can register additional bin script, for example dotenv-cli so i can rewrite my script:

scripts: {
      test: "dotenv-cli -c -- node scripts/my-script"
}

workaround:
use ./node_modules/.bin/dotenv rather than dotenv

I was surprised to find that passing the -c and -e flags together didn’t cause dotenv-cli to check for environment-specific versions of my indicated .env file.

eg.,

dotenv -c production -e ../www/.env …

I was expecting that to expand to ../www/.env.local, ../www/.env.production.local, ../www/.env.production, ../www.env.

I see from the code that this cascading is only performed for the .env file in the same directory. Would there be any interest in giving any -e files the same treatment, either by default or with an extra command line flag?

I was trying to do this:

dotenv echo $HELLO

with .env file looking like:

HELLO=world

and was expecting to get world as a result, but this doesn't work obviously, since $HELLO gets expanded too early.

I was hoping the documentation would give me a hint into how to tweak my command to get the desired result? I'm not that good at bash.

I can make a PR to the documentation when I find how to make it work if you believe other people could find themselves in the same situation.

The Node.js NODE_OPTIONS environment variable allows setting multiple options in a space-separated list, and sometimes it is necessary to set multiple options.

For example

NODE_OPTIONS='--no-experimental-fetch --trace-warnings'

However the current validation regex does not allow for spaces or quotes

$ dotenv -v NODE_ENV=production -v NODE_OPTIONS='--no-experimental-fetch --trace-warnings' next start
Unexpected argument NODE_OPTIONS=--no-experimental-fetch --trace-warnings. Expected variable in format variable=value

The cross-env package allows for this

cross-env NODE_ENV=production NODE_OPTIONS='--no-experimental-fetch --trace-warnings'

I have a production database that I don't want going to GitHub in .env.local and a development generic database credential in .env.development. But since the order puts .env.local after .env.development, that doesn't work.

Suggested load order:
.env > .env.local > .env.development > .env.development.local