2015-07-30 00:12:09 +00:00
# nconf
[![Version npm ](https://img.shields.io/npm/v/nconf.svg?style=flat-square )](https://www.npmjs.com/package/nconf)[![npm Downloads](https://img.shields.io/npm/dm/nconf.svg?style=flat-square)](https://www.npmjs.com/package/nconf)[![Build Status](https://img.shields.io/travis/indexzero/nconf/master.svg?style=flat-square)](https://travis-ci.org/indexzero/nconf)[![Dependencies](https://img.shields.io/david/indexzero/nconf.svg?style=flat-square)](https://david-dm.org/indexzero/nconf)
[![NPM ](https://nodei.co/npm/nconf.png?downloads=true&downloadRank=true )](https://nodei.co/npm/nconf/)
2011-04-02 08:59:18 +00:00
2011-09-19 01:35:55 +00:00
Hierarchical node.js configuration with files, environment variables, command-line arguments, and atomic object merging.
2011-04-02 08:59:18 +00:00
2011-11-24 05:26:32 +00:00
## Example
2015-01-20 18:41:46 +00:00
Using nconf is easy; it is designed to be a simple key-value store with support for both local and remote storage. Keys are namespaced and delimited by `:` . Let's dive right into sample usage:
2011-04-02 08:59:18 +00:00
2011-05-20 03:12:56 +00:00
``` js
2011-04-02 08:59:18 +00:00
var fs = require('fs'),
nconf = require('nconf');
2012-08-07 05:52:29 +00:00
2011-04-02 08:59:18 +00:00
//
2012-08-07 05:52:29 +00:00
// Setup nconf to use (in-order):
2011-11-24 05:26:32 +00:00
// 1. Command-line arguments
// 2. Environment variables
// 3. A file located at 'path/to/config.json'
//
nconf.argv()
.env()
.file({ file: 'path/to/config.json' });
2012-08-07 05:52:29 +00:00
2011-11-24 05:26:32 +00:00
//
// Set a few variables on `nconf` .
2011-04-02 08:59:18 +00:00
//
nconf.set('database:host', '127.0.0.1');
nconf.set('database:port', 5984);
2012-08-07 05:52:29 +00:00
2011-04-02 08:59:18 +00:00
//
2011-09-19 01:34:45 +00:00
// Get the entire database object from nconf. This will output
// { host: '127.0.0.1', port: 5984 }
2011-04-02 08:59:18 +00:00
//
2011-11-24 05:26:32 +00:00
console.log('foo: ' + nconf.get('foo'));
console.log('NODE_ENV: ' + nconf.get('NODE_ENV'));
console.log('database: ' + nconf.get('database'));
2012-08-07 05:52:29 +00:00
2011-04-02 08:59:18 +00:00
//
// Save the configuration object to disk
//
nconf.save(function (err) {
fs.readFile('path/to/your/config.json', function (err, data) {
console.dir(JSON.parse(data.toString()))
});
});
2011-05-20 03:12:56 +00:00
```
2011-04-02 08:59:18 +00:00
2011-11-24 05:26:32 +00:00
If you run the above script:
``` bash
2012-08-07 05:52:29 +00:00
$ NODE_ENV=production sample.js --foo bar
2011-11-24 05:26:32 +00:00
```
The output will be:
```
foo: bar
NODE_ENV: production
database: { host: '127.0.0.1', port: 5984 }
```
2011-09-19 01:34:45 +00:00
## Hierarchical configuration
2011-11-24 05:26:32 +00:00
Configuration management can get complicated very quickly for even trivial applications running in production. `nconf` addresses this problem by enabling you to setup a hierarchy for different sources of configuration with no defaults. **The order in which you attach these configuration sources determines their priority in the hierarchy.** Lets take a look at the options available to you
2015-07-07 20:06:41 +00:00
1. **nconf.argv(options)** Loads `process.argv` using yargs. If `options` is supplied it is passed along to yargs.
2011-11-24 05:26:32 +00:00
2. **nconf.env(options)** Loads `process.env` into the hierarchy.
3. **nconf.file(options)** Loads the configuration data at options.file into the hierarchy.
4. **nconf.defaults(options)** Loads the data in options.store into the hierarchy.
5. **nconf.overrides(options)** Loads the data in options.store into the hierarchy.
A sane default for this could be:
``` js
var nconf = require('nconf');
2012-08-07 05:52:29 +00:00
2011-11-24 05:26:32 +00:00
//
// 1. any overrides
//
nconf.overrides({
'always': 'be this value'
});
2012-08-07 05:52:29 +00:00
2011-11-24 05:26:32 +00:00
//
// 2. `process.env`
// 3. `process.argv`
//
nconf.env().argv();
2012-08-07 05:52:29 +00:00
2011-11-24 05:26:32 +00:00
//
2012-07-10 05:50:18 +00:00
// 4. Values in `config.json`
2011-11-24 05:26:32 +00:00
//
2012-07-10 05:50:18 +00:00
nconf.file('/path/to/config.json');
//
// Or with a custom name
2014-06-18 00:56:42 +00:00
// Note: A custom key must be supplied for hierarchy to work if multiple files are used.
2012-07-10 05:50:18 +00:00
//
nconf.file('custom', '/path/to/config.json');
//
// Or searching from a base directory.
// Note: `name` is optional.
//
nconf.file(name, {
file: 'config.json',
2012-08-07 05:52:29 +00:00
dir: 'search/from/here',
2012-07-10 05:27:28 +00:00
search: true
});
2012-08-07 05:52:29 +00:00
2011-11-24 05:26:32 +00:00
//
// 5. Any default values
//
nconf.defaults({
'if nothing else': 'use this value'
});
```
2011-09-19 01:34:45 +00:00
2011-11-24 05:26:32 +00:00
## API Documentation
2011-09-19 01:34:45 +00:00
The top-level of `nconf` is an instance of the `nconf.Provider` abstracts this all for you into a simple API.
### nconf.add(name, options)
Adds a new store with the specified `name` and `options` . If `options.type` is not set, then `name` will be used instead:
``` js
2014-01-16 22:12:10 +00:00
nconf.add('supplied', { type: 'literal', store: { 'some': 'config' });
2011-11-24 05:26:32 +00:00
nconf.add('user', { type: 'file', file: '/path/to/userconf.json' });
2011-10-20 20:54:47 +00:00
nconf.add('global', { type: 'file', file: '/path/to/globalconf.json' });
2011-09-19 01:34:45 +00:00
```
2012-08-07 05:52:29 +00:00
### nconf.use(name, options)
2011-09-19 01:34:45 +00:00
Similar to `nconf.add` , except that it can replace an existing store if new options are provided
``` js
//
// Load a file store onto nconf with the specified settings
//
2011-10-20 20:54:47 +00:00
nconf.use('file', { file: '/path/to/some/config-file.json' });
2012-08-07 05:52:29 +00:00
2011-09-19 01:34:45 +00:00
//
// Replace the file store with new settings
//
2011-10-20 20:54:47 +00:00
nconf.use('file', { file: 'path/to/a-new/config-file.json' });
2011-09-19 01:34:45 +00:00
```
### nconf.remove(name)
Removes the store with the specified `name.` The configuration stored at that level will no longer be used for lookup(s).
``` js
nconf.remove('file');
```
2011-04-02 08:59:18 +00:00
## Storage Engines
### Memory
2011-04-02 09:13:34 +00:00
A simple in-memory storage engine that stores a nested JSON representation of the configuration. To use this engine, just call `.use()` with the appropriate arguments. All calls to `.get()` , `.set()` , `.clear()` , `.reset()` methods are synchronous since we are only dealing with an in-memory object.
2011-05-20 03:12:56 +00:00
2012-08-07 05:52:29 +00:00
``` js
2011-04-02 09:13:34 +00:00
nconf.use('memory');
2011-05-20 03:12:56 +00:00
```
2011-04-02 08:59:18 +00:00
2011-11-24 05:26:32 +00:00
### Argv
2015-07-07 20:06:41 +00:00
Responsible for loading the values parsed from `process.argv` by `yargs` into the configuration hierarchy. See the [yargs option docs ](https://github.com/bcoe/yargs#optionskey-opt ) for more on the option format.
2011-09-19 01:34:45 +00:00
``` js
//
2015-07-07 20:06:41 +00:00
// Can optionally also be an object literal to pass to `yargs` .
2011-09-19 01:34:45 +00:00
//
2012-08-07 05:52:29 +00:00
nconf.argv({
"x": {
alias: 'example',
describe: 'Example description for usage generation',
demand: true,
default: 'some-value'
}
});
2011-11-24 05:26:32 +00:00
```
### Env
Responsible for loading the values parsed from `process.env` into the configuration hierarchy.
``` js
2011-09-19 01:34:45 +00:00
//
2011-11-24 05:26:32 +00:00
// Can optionally also be an Array of values to limit process.env to.
2011-09-19 01:34:45 +00:00
//
2012-08-07 05:52:29 +00:00
nconf.env(['only', 'load', 'these', 'values', 'from', 'process.env']);
2012-06-21 07:04:06 +00:00
//
// Can also specify a separator for nested keys (instead of the default ':')
//
2012-06-21 07:18:22 +00:00
nconf.env('__');
// Get the value of the env variable 'database__host'
2012-06-21 08:04:37 +00:00
var dbHost = nconf.get('database:host');
2012-06-21 07:18:22 +00:00
//
2014-01-10 00:26:07 +00:00
// Or use all options
2012-06-21 07:18:22 +00:00
//
2012-06-21 07:04:06 +00:00
nconf.env({
separator: '__',
2014-01-10 00:26:07 +00:00
match: /^whatever_matches_this_will_be_whitelisted/
whitelist: ['database__host', 'only', 'load', 'these', 'values', 'if', 'whatever_doesnt_match_but_is_whitelisted_gets_loaded_too']
2012-06-21 07:18:22 +00:00
});
var dbHost = nconf.get('database:host');
2011-11-24 05:26:32 +00:00
```
### Literal
Loads a given object literal into the configuration hierarchy. Both `nconf.defaults()` and `nconf.overrides()` use the Literal store.
``` js
nconf.defaults({
'some': 'default value'
});
2011-09-19 01:34:45 +00:00
```
2011-04-02 08:59:18 +00:00
### File
2014-06-18 00:56:42 +00:00
Based on the Memory store, but provides additional methods `.save()` and `.load()` which allow you to read your configuration to and from file. As with the Memory store, all method calls are synchronous with the exception of `.save()` and `.load()` which take callback functions. It is important to note that setting keys in the File engine will not be persisted to disk until a call to `.save()` is made. Note a custom key must be supplied as the first parameter for hierarchy to work if multiple files are used.
2011-04-02 09:13:34 +00:00
2011-05-20 03:12:56 +00:00
``` js
2012-03-02 18:59:06 +00:00
nconf.file('path/to/your/config.json');
// add multiple files, hierarchically. notice the unique key for each file
nconf.file('user', 'path/to/your/user.json');
nconf.file('global', 'path/to/your/global.json');
2011-05-20 03:12:56 +00:00
```
2011-04-02 09:13:34 +00:00
The file store is also extensible for multiple file formats, defaulting to `JSON` . To use a custom format, simply pass a format object to the `.use()` method. This object must have `.parse()` and `.stringify()` methods just like the native `JSON` object.
2011-04-02 08:59:18 +00:00
2014-01-16 22:05:05 +00:00
If the file does not exist at the provided path, the store will simply be empty.
2011-04-02 08:59:18 +00:00
### Redis
2011-07-08 21:01:22 +00:00
There is a separate Redis-based store available through [nconf-redis][0]. To install and use this store simply:
``` bash
2011-08-28 14:43:44 +00:00
$ npm install nconf
$ npm install nconf-redis
2011-07-08 21:01:22 +00:00
```
Once installing both `nconf` and `nconf-redis` , you must require both modules to use the Redis store:
2011-04-02 09:13:34 +00:00
2011-05-20 03:12:56 +00:00
``` js
2011-07-08 21:01:22 +00:00
var nconf = require('nconf');
2012-08-07 05:52:29 +00:00
2011-07-08 21:01:22 +00:00
//
// Requiring `nconf-redis` will extend the `nconf`
// module.
//
require('nconf-redis');
2012-08-07 05:52:29 +00:00
2011-04-02 09:13:34 +00:00
nconf.use('redis', { host: 'localhost', port: 6379, ttl: 60 * 60 * 1000 });
2011-05-20 03:12:56 +00:00
```
2011-04-02 09:13:34 +00:00
2011-11-21 00:59:33 +00:00
## Installation
### Installing npm (node package manager)
```
curl http://npmjs.org/install.sh | sh
```
### Installing nconf
```
[sudo] npm install nconf
```
2011-04-02 08:59:18 +00:00
## More Documentation
2011-04-02 09:13:34 +00:00
There is more documentation available through docco. I haven't gotten around to making a gh-pages branch so in the meantime if you clone the repository you can view the docs:
2011-05-20 03:12:56 +00:00
```
2011-04-02 09:13:34 +00:00
open docs/nconf.html
2011-05-20 03:12:56 +00:00
```
2011-04-02 08:59:18 +00:00
## Run Tests
Tests are written in vows and give complete coverage of all APIs and storage engines.
2011-05-20 03:12:56 +00:00
2011-09-19 01:34:45 +00:00
``` bash
$ npm test
2011-05-20 03:12:56 +00:00
```
2011-04-02 08:59:18 +00:00
2011-07-08 21:01:22 +00:00
#### Author: [Charlie Robbins](http://nodejitsu.com)
2011-11-21 00:59:33 +00:00
#### License: MIT
2011-07-08 21:01:22 +00:00
2011-11-21 00:59:33 +00:00
[0]: http://github.com/indexzero/nconf-redis