2.0.0 • Published 9 years ago

normalize-env v2.0.0

Weekly downloads
-
License
MIT
Repository
github
Last release
9 years ago

normalize-env

CircleCI branch Coverall Test Coverage Code Climate Dependency Status JavaScript Style Guide

Normalizes node environment variables (a.k.a config vars) for a specific environment (i.e., development, staging etc). Simply put, it converts the contents of a .env file and / or a process.env object that contains entries for various environments such as development and staging etc (i.e., not just for production) into a version that only contains entries for a particular environment.

Install

$ npm install normalize-env -g 

Usage

Normalizing the contents of process.env

Simply add require('normalize-env').normalizeProcessDotEnvObject() to the top of the entry point of your node app and it will convert process.env from this...

{
  DEVELOPMENT__SOME_VAR: 'development value',
  DEVELOPMENT__SOME_OTHER_VAR: 'other development value',
  STAGING__SOME_VAR: 'staging value',
  OTHER__SOME_VAR: 'other value',
  NODE_ENV: 'development',
  SOME_VAR: 'some value'
}

to this...

{
  NODE_ENV: 'production',
  SOME_VAR: 'development value',
  SOME_OTHER_VAR: 'other development value'
}

Note that if the value of process.env.NODE_ENV was instead staging, then the contents of the process.env object would instead be converted to

{
  NODE_ENV: 'staging',
  SOME_VAR: 'staging value'
}

Simply put, normalize-env uses the value of process.env.NODE_ENV to determine the environment that it should normalize to. For situations where there are no environment specific entries (i.e., entries whose keys match the pattern ENV__VAR), then process.env would be normalized to the default. So for instance, if the value of process.env.NODE_ENV was 'production', then process.env would end up being transformed to the following...

{
  NODE_ENV: 'production',
  SOME_VAR: 'some value'
}

Normalizing the contents of a .env file

Given a .env file in a project root that contains something like the following:

DEVELOPMENT__SOME_VAR="development value"
STAGING__SOME_VAR="staging value"
OTHER__SOME_VAR="other value"
SOME_VAR="some value"

To normalize the contents of this for the 'development' environment, run the following command from the project root (i.e., the folder that contains the .env file)

$ normalize-env for devlopment

This will result in the .env file contents becoming

SOME_VAR="development value"

Similarly, if the following command was instead run,

$ normalize-env for staging

the contents of the .env file would become...

SOME_VAR="staging value"

Or if you want to normalize to the default (i.e., remove all environment specific entries from the .env file), then run the command, passing in an environment name that has no corresponding environment specific entries (i.e., entries whose keys match the pattern ENV__VAR) within the .env file. So for instance, running the following command against the same .env file...

$ normalize-env for prodution

...will result in the contents of the .env file becoming:

SOME_VAR="some value"

Motivation

normalize-env was created to help solve the problem of automatically generating environment specific (i.e., production vs staging etc) .env files. It resulted from a need to automate the generation of a development specific .env file from heroku config vars.

Usage with heroku config vars

Start by adding your environment specific config vars to heroku in the same way you would do the production vars. Only this time, prefix the environment specific config vars with the name of the environment, followed by a colon (:). Then once that has been done, run the following commands to pull down and normalize the config vars for a particular environment (substitute 'development' for the name of the environment you want to normalize to)

$ heroku config:pull
$ normalize-env for development

CLI Options

  • -p --path: The path to the env file. E.g., normalize-env for development --path some/.env

Created by

Ifeanyi Isitor

License

MIT © Ifeanyi Isitor

2.0.0

9 years ago

1.1.1

9 years ago

1.1.0

9 years ago

1.0.1

9 years ago

1.0.0

9 years ago

0.7.4

9 years ago

0.7.3

9 years ago

0.7.2

9 years ago

0.7.1

9 years ago

0.7.0

9 years ago

0.6.0

9 years ago

0.5.6

9 years ago

0.5.5

9 years ago

0.5.4

9 years ago

0.5.3

9 years ago

0.5.2

9 years ago

0.5.1

9 years ago

0.5.0

9 years ago

0.4.2

9 years ago

0.4.1

9 years ago

0.4.0

9 years ago

0.3.0

9 years ago

0.2.0

9 years ago