Load .env files and environment variables
Secure and friendly alternative to dotenv, using functional programming, with strong tests to prove its safety.
Follows the Twelve Factor App methodology.
- Safest environment loader around.
- Validates file permissions are secure.
- Validates required env vars are defined.
- No side effects, does not modify
process.env
. - Returns property names in camelCase.
- Asserts that
.env
is ignored in git.
You want to keep your secrets safe, right? envy
loads your app's configuration values from a .env
file and prevents mistakes, such as accidentally committing the .env
file to your repository, or leaving .env
with unsafe permissions.
Have you spent a day rotating passwords because a developer accidentally pushed them to the repository? Yeah, that actually happens and it can cause chaos at companies. It doesn't matter if you delete the commit. Once it's out there, game over. People who are authorized to read the repository may not be authorized to have those credentials, including third party tools and services. If the repository is public, search engines may have crawled it. Consider everything to be compromised.
The envy
module helps you prevent that situation by providing a convenient mechanism for everyone to store credentials and other config locally and validate that it is correct without commiting them to the repository. It verifies that all relevant files have secure permissions and that the secrets file is explicitly ignored so that it cannot accidentally be commited.
npm install envy --save
const envy = require('envy');
const env = envy();
console.log(env);
// {
// foo : 'bar'
// }
A .env.example
file is used as a template to determine which environment variables are required by your application. This file should be commited to your repository.
# .env.example
FOO=
A .env
file is used to provide the actual environment values. You must add this file to a local .gitignore
to prevent leaking secrets and envy
will check that you did this correctly.
# .env
FOO=bar
Environment files look just like normal shell files (e.g. .bashrc
and friends). Values may be optionally wrapped in '
single quotes. This is recommended for shell compatibility, in case the value contains whitespace.
# This is a comment.
FOO=bar
SENTENCE='Hi, there!'
After assembling the environment from .env
and process.env
, it is filtered by a union of the properties in .env
and .env.example
. In other words, variables defined in either file will be returned and variables not defined in either file will be ignored. This is done to prevent surprising behavior, since process.env
often contains a wide variety of variables, some of which are implicitly set without the user's direct knowledge. It is better to be explicit about the variables you use, which improves safety and debugging.
Returns an object
with environment variables derived from process.env
and the contents at filepath
. If a variable is defined in both places, process.env
takes precedence so that users can easily override values on the command line. If all required variables are present in process.env
, then the .env
file need not exist. All property names are returned in camelcase.
Type: string
Default: .env
Path to the file where environment variables are kept. Must be hidden (start with a .
). Will also be used to compute the path of the example file (by appending .example
).
Make a CLI with meow and use joi to further validate and parse the returned values.
// cli.js
const meow = require('meow');
const envy = require('envy');
const joi = require('joi');
const cli = meow();
const input = Object.assign({}, envy(), cli.flags);
const config = joi.attempt(input, {
port : joi.number().positive().integer().min(0).max(65535)
});
// value.port has been parsed as a number
console.log('port:', config.port);
# .env.example
PORT=
# .env
PORT=1000
$ node cli.js
port: 1000
$ PORT=2000 node cli.js
port: 2000
$ node cli.js --port=3000
port: 3000
$ PORT=2000 node cli.js --port=3000
port: 3000
We recommend not using process.env
directly. But let's say you want to because a dependency expects you to set NODE_ENV
and you want to define it in .env
. No problem!
You should first ask the project to accept options as input so you don't need this.
const envy = require('envy');
const decamelize = require('decamelize');
const override = Object.entries(envy()).reduce((result, [key, val]) => {
result[decamelize(key).toUpperCase()] = val;
return result;
}, {});
Object.assign(process.env, override);
I see this as a successor to those projects. But envy
would not exist without them. dotenv
brought .env
files mainstream in Node.js projects. dotenv-safe
improved on it by introducing the .env.example
file. Now, envy
takes this even further by securing your files and returning an object with camelcase keys rather than modifying process.env
.
- Think about sensitive data
- Manage secrets safely
- Remove secrets from a repository
- Store config in the environment
- meow - Make command line apps
See our contributing guidelines for more details.
- Fork it.
- Make a feature branch:
git checkout -b my-new-feature
- Commit your changes:
git commit -am 'Add some feature'
- Push to the branch:
git push origin my-new-feature
- Submit a pull request.
Go make something, dang it.