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 `:`. Lets dive right into sample usage:
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 some sane defaults (in-order):
1. Manually set overrides
2. Command-line arguments
3. Environment variables
4. Any additional user stores (in the order they were added)
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:
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');
```
## Working with Configuration
`nconf` will traverse the set of stores that you have setup in-order to ensure that the value in the store of the highest priority is used. For example to setup following sample configuration:
1. Command-line arguments
2. Environment variables
3. User configuration
3. Global configuration
``` js
var nconf = require('nconf');
//
// Read in command-line arugments and environment variables
//
nconf.argv = nconf.env = true;
//
// Setup the `user` store followed by the `global` store. Note that
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.
Based on the Memory store, but exposes hooks into manual overrides, command-line arguments, and environment variables (in that order of priority). Every instance of `nconf.Provider`, including the top-level `nconf` object itself already has a `System` store at the top-level, so configuring it only requires setting properties
``` js
//
// `nconf.get(awesome)` will always return true regardless of
// command-line arguments or environment variables.
//
nconf.overrides = { awesome: true };
//
// Can also be an object literal to pass to `optimist`.
//
nconf.argv = true;
//
// Can also be an array of variable names to restrict loading to.
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.
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.
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:
