Thoughts on supporting multiple .env files?

Introduced in v8, env-cmd began to exit always with exit code 1.
This is due to the

proc.on('exit', TerminateParentProc)

which then always calls process.exit(1)

With file:

CLIENT_ID=somerandomeid

and command:
./node_modules/.bin/env-cmd .env echo $CLIENT_ID
the result is an empty string. Am I missing anything here?

Here's my file .env-cmdrc

{
  "development": {
    "REACT_APP_NODE_ENV": "development",
    "REACT_APP_API_URL": "/local",
    "PUBLIC_URL": "/"
  },
  "staging": {
    "REACT_APP_NODE_ENV": "staging",
    "REACT_APP_API_URL": "/stage",
    "PUBLIC_URL": "/"
  },
  "production": {
    "REACT_APP_NODE_ENV": "production",
    "REACT_APP_API_URL": "/prod",
    "PUBLIC_URL": "/"
  }
}

And here's my start script

 "start": "env-cmd -e development node scripts/start.js ",

It fails with error

Error: Invalid .rc file path.
at Object. (/Users/xxx/.Trash/yyy/node_modules/env-cmd/dist/parse-rc-file.js:27:19)
at Generator.throw ()
at rejected (/Users/xxx/.Trash/yyy/node_modules/env-cmd/dist/parse-rc-file.js:5:65)

Same setup is being run in another project. Can't figure out why is this happening!

Could you publish a guide showing how to upgrade from env-cmd@9 to env-cmd@10?

Hi,

I am using env-cmd in versin 9.0.3 and greenkeeper just got me the update in. I tried it out and the command just fail with sh: line 1: 4041 Terminated: 15. I checked the changelogs but cannot find any breaking change affecting me, since I use vanilla NodeJS 12.8.1.

An example command as I have it in my package.json:
env-cmd cross-env DEBUG=false KNEX_SEED_DIR=./seeds/resetdb knex seed:run

I need to use the default .env file within my system and then override some env vars with cross-env. I would guess something about parsing this line has changed.

Maybe you can help me either "rewrite" the script so that I actually do not need both env-cmd and cross-env, or we find the bug breaking my script in the latest update.

Thanks!

I have a start script to run my express server:
"start": "env-cmd ./.env node ./dist/server.js"
When it runs my express app starts listening on some port
When I hit CTRL+C it exists but the node precess of express still alive

I use windows 10 but I think it's an issue of spawn, you spawn a process and dont send he signal to it when you recieve it...

I'm trying to use cmd-env to help templatize my aws calls from yarn but I'm not able to get the variables...

for example
npx env-cmd -e production echo $FOO returns nothing when I'd expect it to return BAR

but npx env-cmd -e production printenv FOO returns BAR

How can I access to the env vars so I can pipe them into other commands as parameters?

Hi,

I was wondering why you didn't handle to make env-cmd not crashing and continue to run node when the .env file doesn't exist.

This the error I got when I try :

WARNING:
      Could not find or read file at:
       /server/.env
      Trying to fallback to read:
       /server/.env

Error! Could not fallback to find or read file at /server/.env

I've found a way to do what I want to do but env-cmd could handle it :

   "scripts": {
        "start": "env-cmd --no-override .env node . || node ."
    }

I suggest replacing src/parse-env-file.ts:58
with

.replace(/\\n/g, '\n')

I've installed env-cmd and added the following script:

"env-cmd ./.env react-scripts start"

My .env file is in the root of my project and contains the following data:

SOME_KEY=foo

Running console.log(process.env.SOME_KEY); shows undefined, however.

Is there anything I've missed?

I consistently received 'permission denied' error when trying to run env-cmd in Kubuntu 18.04

I also couldn't use a non-default file location without the '-f' switch in v8 and also could not with the '-f' switch in v9.

I realize these are technically different issues, but I suspect they have similar origins because I was following a tutorial on Udemy and none of the Mac or Windows users reported any similar problem. It could even be something I was doing wrong, but I followed the example code precisely without success.

I posted a question on StackOverflow with all the details so I won't repeat them here.

Here is the link the SO post:

https://stackoverflow.com/questions/56317034/permission-denied-when-running-npm-module-that-sets-environment-variables-in-nod

Hi Todd.
If my project doesn't have a .env file, my command
env-cmd node etcetc
Will fail with:

Error: Unable to locate env file at default locations (./.env,./.env.js,./.env.json)
at getEnvFile (C:\workspace\so-ui-e2e-test\node_modules\env-cmd\dist\get-env-vars.js:34:11)

But look, I don't want to commit a .env file to my repository. Meaning when my CI clones and tries to run the project, there isn't a .env file there, and the CI build will fail.

Not having a .env file from which to load should be no worries, because I can
$PORT=1234 API_KEY=${secret_key} npm run start
in the CI environment.

But now you're making me commit my (empty) .env file so that CI doesn't fail, well it's only going to be a matter of time before someone commits their dev secrets to the repository.

IMHO you should allow the scripts to run if you don't find a .env file, just throw a warning with output to console, what do you think?

For example, in this package.json:

{
···
  "scripts": {
    "mycmd-1": "env-cmd ./env1 The-command",
    "mycmd-2": "env-cmd ./env2 The-command"
  },
···
}

Then, the 2 env files:

• ./env1:

COMMON=123

• ./env2:

COMMON=123
SPECIFIC=abc

The common variable COMMON have to modified in the 2 files.
With an import of env1 into env2, the common variable must just be modified in the ./env1 env file.

This could be declared in ./env2 like that:

@import=./env1
SPECIFIC=abc

Hello,

Should it fail when no --fallback option is provided?

I have the following

// package.json
"build:preprod": "env-cmd ./config/.env.preprod webpack --config webpack/webpack.prod.js",

It'd be helpful if it failed when ./config/.env.preprod is not found.

We're using env-cmd in our build process, and the most recent change to require a -f parameter for a custom env file location should have failed our builds.

Unfortunately it didn't, it just displays a warning in our build output, and CircleCI still marked it as a passing build, even though we hadn't actually deployed anything:

Looks like this behaviour is already deprecated (DEP0018) and will be fixed in Node.js someday, but in the meanwhile it would be helpful if env-cmd signalled Node to return a non-zero exit status.

We use AWS S3 to host some of our assets and add the route to the env file. For development, we use an S3 bucket per developer. The bucket name is determined by the bash command "whoami".

For example:

# .env.development
CDN=https://s3.amazonaws.com/<our_org>/{{whoami}}

I'm trying to migrate to env-cmd. Is there a recommended way to do this? Or any ideas?

Basically, I want to evaluate {{whoami}} to the actual value, thus when running env-cmd .env.development node index.js, the CDN env variable would be for example: CDN=https://s3.amazonaws.com/<our_org>/johndoe.

The devDependency @types/node was updated from 12.6.8 to 12.6.9.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

This is a bug in the latest version of this package. Works fine with 8.0.2, but not with 9.0.1.

I have a Create React App and run this command:

    "build:test": "env-cmd .env.test yarn run build",

I get the following error:

spawn .env.test ENOENT
/bin/sh: line 1: 58663 Hangup: 1               env-cmd .env.test yarn run build

The devDependency @typescript-eslint/eslint-plugin was updated from 1.9.0 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/eslint-plugin is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

why JWT_KEY is only undefined?

// code

console.log(process.env.MONGODB_URL);
console.log(process.env.JWTKEY);
console.log(process.env.PORT);

The devDependency @types/node was updated from 12.0.6 to 12.0.7.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I tried the third of .env, .json, .js, neither work with a string with newlines inside.

.env

TEST=abc\ndef

TEST="abc
def"

.json

{ "TEST": "abc\ndef" }

.js

module.exports = {
  "TEST": `abc
def`
}

module.exports = {
  "TEST": "abc\ndef"
}

None of this works, this is pretty annoying for private keys, especially.

This produces a raw string with \n (\\n actualy) inside

I am trying to set env variable through terminal like,
node node_modules/env-cmd -f ./async-env.js node index.js

getting below error.. Please assist
TypeError: util_1.promisify is not a function
at Object. (/node_modules/env-cmd/dist/parse-rc-file.js:15:26)
at Module._compile (module.js:570:32)
at Object.Module._extensions..js (module.js:579:10)
at Module.load (module.js:487:32)
at tryModuleLoad (module.js:446:12)
at Function.Module._load (module.js:438:3)
at Module.require (module.js:497:17)
at require (internal/module.js:20:19)
at Object./node_modules/env-cmd/dist/get-env-vars.js:11:25)
at Module._compile (module.js:570:32)

I have these scripts in my package.json:

"start": "env-cmd ./.env.dev.local node server",
"start:prod": "env-cmd ./.env.local node server",

I would like the .env.dev.local to fallback to .env.dev and the .env.local to fallback to .env file. Is this possible?

Basically change Object.assign({}, process.env) to Object.assign(process.env).

I'm on Windows 10 with NodeJS v12.11.1

env-cmd version: 10.0.1
cross-env version: 6.0.3

The command I'm running is:
cross-env NODE_ENV=development env-cmd .env node server

I get this error message for the .env file is:
This file does not have an app associated with it for performing this action. Please install an app or, if one is already installed, create an association in the Default Apps Settings page.

This does not happen when using env-cmd version 8.0.2

I'm trying to pass a custom file location by using:

env-cmd -f env.sandbox

but it keeps complaining that:

Error: Unable to locate env file at default location (./.env)

In some cases , to be coherent across all the tooling , I need the resulting env object programmatically rather than as env vars.

Basically any path other than a local .env-whatever does not seem to work when using at runtime with nuxt start (just as my personal real life usecase).
It would be awesome to use something like /etc/my_project.conf.env if possible?

Cheers

From some point I can't run yarn build, with that error. The last thing I updates was node version, rolling back to old one doesn't help, so I am not sure this is the reason. Any way to fix this? I have .env.staging file in the root directory.

I'm trying to launch webpack with environment variables so in my packages.json I do:

env-cmd production webpack --bail

But this returns:

> env-cmd production webpack --bail

spawn webpack ENOENT

I assumed this was because it hasn't activated node_modules/ in its path but even if I work around this:

./node_modules/env-cmd/bin/env-cmd.js production node ./node_modules/webpack/bin/webpack.js
spawn node ENOENT

The only thing that works is:

./node_modules/env-cmd/bin/env-cmd.js node ./node_modules/webpack/bin/webpack.js

but I have no idea what environment that is running?

env-cmd 9.0.3
env: Windows 10 WSL2

env-cmd -f ./.env.staging my-build-script                             
Error: spawn EPERM
    at ChildProcess.spawn (internal/child_process.js:394:11)                                                                at Object.spawn (child_process.js:535:9)                                                                                
at Object.spawn (/home/jdunlap/n/lib/node_modules/env-cmd/node_modules/cross-spawn/index.js:12:24)                      at Object.<anonymous> (/home/jdunlap/n/lib/node_modules/env-cmd/dist/env-cmd.js:57:30)                                  
at Generator.next (<anonymous>)
    at fulfilled (/home/jdunlap/n/lib/node_modules/env-cmd/dist/env-cmd.js:4:58) {                                        errno: 'EPERM',                                                                                                         
code: 'EPERM',                                                                                                          
syscall: 'spawn'                                                                                                      
}

I know JSON doesn't allow comments, but does the rc file really have to be strict JSON?
It'd be nice to be able to comment there.

I'm not sure exactly what's going on here, but there appears to have been a breaking change between versions 8.0.2 and 9.0.0 which causes failure of my react-scripts builds.

I'm building on Ubuntu 18.04. The problem also exists and exhibits identical behaviour when building in a Debian Stretch environment in Docker.

The relevant part of my package.json:

"scripts": {
    "build:production": "env-cmd .env.production react-scripts build"
  },

The error:

> [email protected] build:docker /home/dev/react
> env-cmd .env.docker react-scripts build
Error: Unable to locate env file at default location (./.env)
    at /home/dev/react/node_modules/env-cmd/dist/get-env-vars.js:44:19
    at Generator.throw (<anonymous>)
    at rejected (/home/dev/react/node_modules/env-cmd/dist/get-env-vars.js:5:65)
    at <anonymous>
    at runMicrotasksCallback (internal/process/next_tick.js:121:5)
    at _combinedTickCallback (internal/process/next_tick.js:131:7)
    at process._tickCallback (internal/process/next_tick.js:180:9)
    at Function.Module.runMain (module.js:695:11)
    at startup (bootstrap_node.js:188:16)
    at bootstrap_node.js:609:3
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build:docker: `env-cmd .env.docker react-scripts build`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] build:docker script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/dev/.npm/_logs/2019-06-05T22_45_47_875Z-debug.log

Versions up to 8.0.2 work flawlessly using the above scripts declaration. I have tested using exactly the same app, in the same environment, with the only different variable being the version of env-cmd. Switching to < 9.0.0 is fine, but upgrading to 9.0.0 and above breaks the build.

Hey just wanted to say cool project! Thanks.

This is more of a feature request than an issue, but it seems this is using a pattern of multiple .env files. I think this is cool but in node land my root folder is filling up with cruft.

What I would love for this project is to have just the one .envrc file in my root that has multiple configurations inside (preferably in json).

ie (.envrc)

{
    "debug": {
         "NODE_ENV": "development"
    },
    "release": {
        "NODE_ENV": "production"
    }
}

Then this could allow me to define the variables in a npm script like this:

(package.json)

"scripts": {
    "build": "env-cmd release webpack",
    "watch": "env-cmd debug webpack --watch"
}

What do you think?

And thanks again for sharing your project.
Jenna

Hi.
The engines property in the package.json says that node version >= 4.0 is supported.
Will it really work with node versions < 6.0? (don't support let, etc.)

Thanks.

Basically, this example pretty much sums up what I want to do.

Although, I'll provide you with my use-case.

I have a secret key called API_KEY that I want to access inside of package.json's scripts.

package.json

{
   "scripts": {
      "start": "web-ext run --api-key=API_KEY"
   }
}

My .env file contains API_KEY which I want to keep private:

API_KEY=abc123

Now if I use cmd-env, I can't pass it as an argument to --api-key

I want the following to work 👇

{
   "scripts": {
      "start": "cmd-env web-ext run --api-key=$API_KEY"
   }
}

Any way to add that?

Tried the following command in NPM but it does not work as expected on macOS.

# package.json

{
 "scripts": {
  "start": "env-cmd ~/some-secrets.env node ./dist/server",
 }
}

# Warning message shows an incorrect path to read the ENV file.

$ npm run start

WARNING:
      Could not find or read file at:
        /Users/my-mac/test-repo/Users/my-mac/some-secrets.env
      Trying to fallback to read:
        /Users/my-mac/test-repo/.env

Hey. Nice project.

Passwords with # do not work, event when quoted. You may want to look into that

Hello, if I run env-cmd ./config.env webpack --progress, I wish all variables defined in source index.js translated to correspondent constant in output bundle.js . e.g:

config.env

FOO=foo
BAR=bar

index.js

var x = [ENV.FOO, ENV.BAR]

bundle.js

var x = ["foo", "bar"]

The devDependency @typescript-eslint/parser was updated from 1.9.0 to 1.10.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@typescript-eslint/parser is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

I'm trying to use the support for .env-cmdrc.js along with the --environments flag to allow me to do merging of environments within the environments file to avoid my scripts from getting too long.

Unfortunately it seems like there's a bug in env-cmd around resolving the fallback files. I can see where the code is set up to try and do that, but it fails on the first file.

I've created a repro as a gist

Here's the error I get when trying to use env-cmd with a .env-cmdrc.js file in the same dir:

Error: Invalid .rc file path.
    at Object.<anonymous> (C:\Users\tivac\Desktop\env-cmd-test\node_modules\env-cmd\dist\parse-rc-file.js:27:19)
    at Generator.throw (<anonymous>)
    at rejected (C:\Users\tivac\Desktop\env-cmd-test\node_modules\env-cmd\dist\parse-rc-file.js:5:65)

• [email protected]
• [email protected]
• [email protected]

It would be great to be able to use env variable sources of multiple types, e.g. pull some variables from the .env-cmdrc file as well as a .env.local file.

The use case for this would be for instance to have a cleanly-defined .env-cmdrc with all "regular" environments (development, test, staging, production...) containing non-sensible data that could be committed, along with a .env.local file that would stay uncommitted, where some passwords, tokens or security-related stuff would be put, mainly for development purposes (in production, those variables could be replaced by hidden variables outside of the project's scope).

The syntax could be quite similar to the existing one to import multiple environment groups from an rc file, like this : env-cmd development,./.env.local .... The problem today is you can't do that, it seems from the moment you have a rc file in your repo it will not try to resolve the provided env filename to something else than a root property in the rc file. Indeed with the syntax I just provided, the .env.local file seems to be completely ignored, and if used exclusively without the development environment, it spawns the following error :

Error: could not find environment:
    .env.local
  in .rc file

It is possible to use a JS file export instead of the rc file, in which we import from a non-committed JS file the sensible data and destructure it in the targeted environment's object property. But IMHO it is less clean and less expressive than properly declaring that you expect a local env file to be provided for some scripts like start or inspect for instance. It is also visually more cluttered since instead of a simple env-cmd development command, you have something like env-cmd ./.env.development.js. For reference, this is what I currently did:

// ./.env.development.js
const localEnv = require('./.env.local');

module.exports = {
  FOO: 'foo',
  BAR: 'bar',
  ...localEnv,
};

// ./.env.local.js
module.exports = {
  FOO: 'override-foo',
  SUPER_SECRET_TOKEN: 'xyz',
};

Do you think this would be useful? Is my approach regarding the JS file correct? How would you do to combine several environments with some of them being committed and not others (I'm really talking about combining them, not duplicating the whole development environment in a .env.local file and using that for local dev scripts) without requiring to JS file configs?

Thanks 🙂

Sometimes commands have the same pattern, like this in thi package.json:

{
...
  "scripts": {
    "cmd1": "env-cmd --fallback ./.env.local The-Command-1",
    "cmd2": "env-cmd --fallback ./.env.local The-Command-2",
    "cmd3": "env-cmd --fallback ./.env.local The-Command-3",
    "cmd4": "env-cmd --fallback ./.env.local The-Command-4",
    "cmd5": "env-cmd --fallback ./.env.local The-Command-5"
  },
...
}

That could help if this can be simplifed like that:

{
...
  "scripts": {
    "cmd1": "env-cmd -d The-Command-1",
    "cmd2": "env-cmd -d The-Command-2",
    "cmd3": "env-cmd -d The-Command-3",
    "cmd4": "env-cmd -d The-Command-4",
    "cmd5": "env-cmd -d The-Command-5"
  },
...
}

With a new option -d and --defaults which define --fallback ./env.local as the default.

This would be nice to allow things like setting defaults, and could be massaged into an alternative approach for #7.

I am trying to have .env.local fallback to .env.development.

I tried env-cmd ./.env.local --fallback ./.env.development node src/server/index.js

but it does not work.

Is there a way to make it work?

A space after the environment var breaks the script; however, a space after the equal sign still works... I am concerned about a common scenario, where one may set ENV = VALUE (space before and after the equal sign).

# ENV2 breaks, while ENV3 works
ENV2 =FOR ALL
ENV3= THE FISH

react-scripts v3.0.0 (also tried with 2.1.8)
env-cmd v9.0.1

I just upgraded packages on an older project and the build stopped working. When I try to run the build script locally in Windows it is showing a "How do you want to open this file" prompt to open the ".env.vnext" file. If I do a plain yarn build, it works as expected.

Here's the script in question:
"build:vnext": "env-cmd .env.vnext react-scripts build" => yarn build:vnext

I deleted the node_modules and yarn.lock files and ran yarn install again to make sure there wasn't something weird with package versions. I also tried reverting the react-scripts version back to 2.1.8. Neither of those fixed it.

I then reverted the env-cmd package back to version to 8.0.2, and yarn build:vnext works again.

[EDIT] This might be somewhat related to issue #61, but my scenario is different enough that I figured I'd type it up.