Package Exports
- env-cmd
This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (env-cmd) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.
Readme
env-cmd
A simple node program for executing commands using an environment from an env file.
Install
npm install env-cmd or npm install -g env-cmd
Basic Usage
Environment file ./test/.env
# This is a comment
ENV1=THANKS
ENV2=FOR ALL
ENV3=THE FISHPackage.json
{
"scripts": {
"test": "env-cmd ./test/.env mocha -R spec"
}
}or
Terminal
./node_modules/.bin/env-cmd ./test/.env node index.jsAdvanced Usage
--fallback file usage option
You can specify an .env.local (or any name) env file, add that to your .gitignore and use that in your local development environment. Then you can use a regular .env file in root directory with production configs that can get committed to a private/protected repo. When env-cmd cannot find the .env.local file it will fallback to looking for a regular .env file.
Environment file ./.env.local
# This is a comment
ENV1=THANKS
ENV2=FOR ALL
ENV3=THE FISHFallback Environment file ./.env
# This can be used as an example fallback
ENV1=foo
ENV2=bar
ENV3=baz
ENV4=quux
ENV5=gorgePackage.json
uses ./.env as a fallback
{
"scripts": {
"test": "env-cmd --fallback ./.env.local mocha -R spec"
}
}or
Terminal
# uses ./.env as a fallback, because it can't find `./.env.local`
./node_modules/.bin/env-cmd ./.env.local node index.js.rc file usage
For more complex projects, a .env-cmdrc file can be defined in the root directory and supports as many environments as you want. Instead of passing the path to a .env file to env-cmd, simply pass the name of the environment you want to use thats in your .env-cmdrc file. You may also use multiple environment names to merge env vars together.
.rc file .env-cmdrc
{
"development": {
"ENV1": "Thanks",
"ENV2": "For All"
},
"test": {
"ENV1": "No Thanks",
"ENV3": "!"
},
"production": {
"ENV1": "The Fish"
}
}Terminal
./node_modules/.bin/env-cmd production node index.js
# Or for multiple environments (where `production` vars override `test` vars,
# but both are included)
./node_modules/.bin/env-cmd test,production node index.js--no-override option
Sometimes you want to set env variables from a file without overriding existing process env vars or shell env vars.
Terminal
ENV1=welcome ./node_modules/.bin/env-cmd --no-override ./test/.env node index.jsEnvironment File Formats
These are the currently accepted environment file formats. If any other formats are desired please create an issue.
key=value- Key/value pairs as JSON
- JavaScript file exporting an object
.env-cmdrcfile (as valid json) in execution directory
Path Rules
This lib attempts to follow standard bash path rules. The rules are as followed:
Home Directory = /Users/test
Working Directory = /Users/test/Development/app
| Type | Input Path | Expanded Path |
|---|---|---|
| Absolute | /some/absolute/path.env |
/some/absolute/path.env |
Home Directory with ~ |
~/starts/on/homedir/path.env |
/Users/test/starts/on/homedir/path.env |
| Relative | ./some/relative/path.env or some/relative/path.env |
/Users/test/Development/app/some/relative/path.env |
| Relative with parent dir | ../some/relative/path.env |
/Users/test/Development/some/relative/path.env |
Why
Because sometimes its just too cumbersome passing lots of environment variables to scripts. Its usually just easier to have a file with all the vars in them, especially for development and testing.
Do not commit sensitive environment data to a public git repo!
Related Projects
cross-env - Cross platform setting of environment scripts
Special Thanks
Special thanks to cross-env for inspiration (use's the same cross-spawn lib underneath too).
Contributors
- Eric Lanehart
- Jon Scheiding
- Alexander Praetorius
- Anton Versal
Contributing Guide
I welcome all pull requests. Please make sure you add appropriate test cases for any features added. Before opening a PR please make sure to run the following scripts:
npm run lintchecks for code errors and formats according to js-standardnpm testmake sure all tests passnpm run test-covermake sure the coverage has not decreased from current master