motdotla/dotenv — pull request #46 by maxbeatty (2014-12-31 18:12:21+00:00)
Title: 1.0 Proposal

Here's my proposal for 1.0 of dotenv. The primary motivation is to clean up the implementation and tests, but in doing that some features had to be removed. The same behavior can be accomplished with minimal additional code by end users thanks to the new options argument.

_It's probably easiest to review this by checking out, running some gulp tasks, and looking at the code as a whole instead of diffs_

## Goals

- keep dependency free
- simplify public API
- simpler underlying code (remove unnecessary loops, vaguely named "private functions")
- organize tests by area of responsibility (`parse` tests were under `load`, "private" fuctions tested implicitly)
- make it easier to contribute (guides, styles, more organized code)

## Additions

- add support for node 0.11
- add eslint to maintain coding style and best practices
- add istanbul to measure code coverage
- publish coverage results to coveralls for easy tracking
- Contributing.md will be shown on every PR (also provides gulp task docs)
- more documentation especially around parse rules with examples
- custom encoding when reading .env file (minor but easy)
- lock down versions of devDependencies

## Removals

- no longer support node 0.6 and 0.8
- no longer support `.env.environment` loading (bad practice but still possible by end users if they call `config` multiple times)
- simplified `.gitignore` for what our project uses

## Changes

Incompatible API changes hence major version change.

- change `load` to `config` and take options for custom path and encoding (partially to spell out this is a big change and partially to reinforce 12factor purpose)

## Upgrading

Anyone using a simple implementation of dotenv will just need to change `load` to `config` if they decide to upgrade at all.

Anyone relying on more of the internals of dotenv to handle multiple environment files will need to add a line to their current implementation. Most likely:

```js
var dotenv = require("dotenv");
dotenv.config(); // .env
dotenv.config({path: ".env." + process.env.NODE_ENV});
```

`NODE_ENV` can either be set in .env or in the environment before starting the node process.

Anyone loading a custom file path should have an easier, cleaner time with the addition of the `path` option. No more calling multiple "private"-looking functions.

Anyone using `parse` will not notice any differences.

---
(Pay no attention to the branch name. I originally thought I wanted to use streams, but given their async nature and the sync usage of dotenv, it turned out to be a poor choice.)