1 | # nconf [![Build Status](https://secure.travis-ci.org/flatiron/nconf.png)](http://travis-ci.org/flatiron/nconf)
|
2 |
|
3 | Hierarchical node.js configuration with files, environment variables, command-line arguments, and atomic object merging.
|
4 |
|
5 | ## Installation
|
6 |
|
7 | ### Installing npm (node package manager)
|
8 | ```
|
9 | curl http://npmjs.org/install.sh | sh
|
10 | ```
|
11 |
|
12 | ### Installing nconf
|
13 | ```
|
14 | [sudo] npm install nconf
|
15 | ```
|
16 |
|
17 | ## Getting started
|
18 | 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:
|
19 |
|
20 | ``` js
|
21 | var fs = require('fs'),
|
22 | nconf = require('nconf');
|
23 |
|
24 | //
|
25 | // Setup nconf to use the 'file' store and set a couple of values;
|
26 | //
|
27 | nconf.add('file', { file: 'path/to/your/config.json' });
|
28 | nconf.set('database:host', '127.0.0.1');
|
29 | nconf.set('database:port', 5984);
|
30 |
|
31 | //
|
32 | // Get the entire database object from nconf. This will output
|
33 | // { host: '127.0.0.1', port: 5984 }
|
34 | //
|
35 | console.dir(nconf.get('database'));
|
36 |
|
37 | //
|
38 | // Save the configuration object to disk
|
39 | //
|
40 | nconf.save(function (err) {
|
41 | fs.readFile('path/to/your/config.json', function (err, data) {
|
42 | console.dir(JSON.parse(data.toString()))
|
43 | });
|
44 | });
|
45 | ```
|
46 |
|
47 | ## Hierarchical configuration
|
48 |
|
49 | 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):
|
50 |
|
51 | 1. Manually set overrides
|
52 | 2. Command-line arguments
|
53 | 3. Environment variables
|
54 | 4. Any additional user stores (in the order they were added)
|
55 |
|
56 | The top-level of `nconf` is an instance of the `nconf.Provider` abstracts this all for you into a simple API.
|
57 |
|
58 | ### nconf.add(name, options)
|
59 | Adds a new store with the specified `name` and `options`. If `options.type` is not set, then `name` will be used instead:
|
60 |
|
61 | ``` js
|
62 | nconf.add('global', { type: 'file', file: '/path/to/globalconf.json' });
|
63 | nconf.add('userconf', { type: 'file', file: '/path/to/userconf.json' });
|
64 | ```
|
65 |
|
66 | ### nconf.use(name, options)
|
67 | Similar to `nconf.add`, except that it can replace an existing store if new options are provided
|
68 |
|
69 | ``` js
|
70 | //
|
71 | // Load a file store onto nconf with the specified settings
|
72 | //
|
73 | nconf.use('file', { file: '/path/to/some/config-file.json' });
|
74 |
|
75 | //
|
76 | // Replace the file store with new settings
|
77 | //
|
78 | nconf.use('file', { file: 'path/to/a-new/config-file.json' });
|
79 | ```
|
80 |
|
81 | ### nconf.remove(name)
|
82 | Removes the store with the specified `name.` The configuration stored at that level will no longer be used for lookup(s).
|
83 |
|
84 | ``` js
|
85 | nconf.remove('file');
|
86 | ```
|
87 |
|
88 | ## Working with Configuration
|
89 | `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:
|
90 |
|
91 | 1. Command-line arguments
|
92 | 2. Environment variables
|
93 | 3. User configuration
|
94 | 3. Global configuration
|
95 |
|
96 | ``` js
|
97 | var nconf = require('nconf');
|
98 |
|
99 | //
|
100 | // Read in command-line arugments and environment variables
|
101 | //
|
102 | nconf.argv = nconf.env = true;
|
103 |
|
104 | //
|
105 | // Setup the `user` store followed by the `global` store. Note that
|
106 | // order is significant in these operations.
|
107 | //
|
108 | nconf.add('user', { file: 'path/to/user-config.json' });
|
109 | nconf.add('global', { file: 'path/to/global-config.json' })
|
110 | ```
|
111 |
|
112 | ## Storage Engines
|
113 |
|
114 | ### Memory
|
115 | 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.
|
116 |
|
117 | ``` js
|
118 | nconf.use('memory');
|
119 | ```
|
120 |
|
121 | ### System
|
122 | 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
|
123 |
|
124 | ``` js
|
125 | //
|
126 | // `nconf.get(awesome)` will always return true regardless of
|
127 | // command-line arguments or environment variables.
|
128 | //
|
129 | nconf.overrides = { awesome: true };
|
130 |
|
131 | //
|
132 | // Can also be an object literal to pass to `optimist`.
|
133 | //
|
134 | nconf.argv = true;
|
135 |
|
136 | //
|
137 | // Can also be an array of variable names to restrict loading to.
|
138 | //
|
139 | nconf.env = true;
|
140 | ```
|
141 |
|
142 | ### File
|
143 | 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.
|
144 |
|
145 | ``` js
|
146 | nconf.use('file', { file: 'path/to/your/config.json' });
|
147 | ```
|
148 |
|
149 | 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.
|
150 |
|
151 | ### Redis
|
152 | There is a separate Redis-based store available through [nconf-redis][0]. To install and use this store simply:
|
153 |
|
154 | ``` bash
|
155 | $ npm install nconf
|
156 | $ npm install nconf-redis
|
157 | ```
|
158 |
|
159 | Once installing both `nconf` and `nconf-redis`, you must require both modules to use the Redis store:
|
160 |
|
161 | ``` js
|
162 | var nconf = require('nconf');
|
163 |
|
164 | //
|
165 | // Requiring `nconf-redis` will extend the `nconf`
|
166 | // module.
|
167 | //
|
168 | require('nconf-redis');
|
169 |
|
170 | nconf.use('redis', { host: 'localhost', port: 6379, ttl: 60 * 60 * 1000 });
|
171 | ```
|
172 |
|
173 | ## More Documentation
|
174 | 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:
|
175 |
|
176 | ```
|
177 | open docs/nconf.html
|
178 | ```
|
179 |
|
180 | ## Run Tests
|
181 | Tests are written in vows and give complete coverage of all APIs and storage engines.
|
182 |
|
183 | ``` bash
|
184 | $ npm test
|
185 | ```
|
186 |
|
187 | #### Author: [Charlie Robbins](http://nodejitsu.com)
|
188 |
|
189 | [0]: http://github.com/indexzero/nconf
|