+2
-3
| { | ||
| "name": "gestalt", | ||
| "version": "0.0.9", | ||
| "version": "0.1.0", | ||
| "author": "Chris Howe <chris@howeville.com>", | ||
@@ -25,4 +25,3 @@ "description": "Event driven configuration management.", | ||
| "devDependencies": { | ||
| "vows": ">= 0.6.2", | ||
| "zookeeper": ">= 3.4.0" | ||
| "vows": ">= 0.6.2" | ||
| }, | ||
@@ -29,0 +28,0 @@ "bundleDependencies": [ |
+42
-51
@@ -10,21 +10,20 @@ # gestalt | ||
| There are a couple of motivations for gestalt: Configuration of a | ||
| large software system is often complicated - there are of course many | ||
| tools out there for gathering configuration information from a bunch | ||
| of different sources. nconf for node is a good one, and gestalt is to | ||
| some extent based upon it. Gestalt is also influenced by configliere | ||
| for ruby and the configuration node structure of chef. However, there | ||
| are a couple of things that many of these tools do not do well. First, | ||
| configuration files (and other sources) can change, and it would be | ||
| nice to be able to react to these changes on-the-fly. Second, for a | ||
| sufficiently complicated system of default and override configuration | ||
| sources, it can become difficult to figure out exactly where a | ||
| particular setting came from. | ||
| Configuration of a large software system is often complicated - there | ||
| are of course many tools out there for gathering configuration | ||
| information from a bunch of different sources. nconf for node is a | ||
| good one, and gestalt is to some extent based upon it. Gestalt is also | ||
| influenced by configliere for ruby and the configuration node | ||
| structure of chef. However, there are a couple of things that many of | ||
| these tools do not do well. First, configuration files (and other | ||
| sources) can change, and it would be nice to be able to react to these | ||
| changes on-the-fly. Second, for a sufficiently complicated system of | ||
| default and override configuration sources, it can become difficult to | ||
| figure out exactly where a particular setting came from. | ||
| Gestalt solves both of these problems. It has a per-value event change | ||
| tracking system so that you can track changes to individual settings | ||
| to your configuration. It also rigorously keeps track of where the | ||
| values for particular settings came from. | ||
| to your configuration. It also rigorously tracks the sources of configuration | ||
| values and can generate a complete report of all values and sources. | ||
| ## Basics | ||
| ## Usage | ||
@@ -77,4 +76,4 @@ The basic object is a Configuration: | ||
| It is possible to turn a configuration object back into a regular | ||
| object. Also, if a configuration object looks like an array (all | ||
| integer keys...) toObject will in fact return an array. | ||
| object. If a configuration object looks like an array (all | ||
| integer keys, contiguous from zero) toObject will in fact return an array. | ||
@@ -103,20 +102,9 @@ ## Events | ||
| Configuration objects also have a ready/invalid/other state. When | ||
| everything about the configuration is loaded the way it expects that | ||
| it should be, it enters a 'ready' state. If something has gone wrong | ||
| in a way that might require some attention, it enters an 'invalid' | ||
| state. Other states are possible - most configuration objects start in | ||
| a 'not ready' state, but particular implementations might add some other | ||
| special states. | ||
| Configuration objects also have a ready/invalid/other state. State | ||
| propagates from children to parents and from contained objects to | ||
| containers. On state transitions (and whenever further 'invalid' | ||
| states are encountered) configuration objects will emit a 'state' | ||
| message. The payload object is of the form: | ||
| State propagates from children to parents and from contained objects | ||
| to containers. The parent/container will become invalid if any of its | ||
| children/contents become 'invalid'. Also, a parent/container will only become | ||
| 'ready' if all of its children/contents are 'ready'. If no sub-configuration | ||
| is invalid, but not all of them are ready, parents and containers become | ||
| 'not ready'. | ||
| On state transitions (and whenever further 'invalid' states are | ||
| encountered) configuration objects will emit a 'state' message. The | ||
| payload object is of the form: | ||
@@ -130,3 +118,3 @@ ```javascript | ||
| To reiterate, there are three main states a Configuration object can | ||
| There are three main states a Configuration object can | ||
| be in: | ||
@@ -211,3 +199,6 @@ | ||
| configuration object that is being remapped. Second, it needs a function | ||
| that will map names from the original object into the new object space. | ||
| that will map names from the original object into the new object space. Optionally, | ||
| you can provide a function that maps new configuration names back to the old | ||
| configuration names - this is only really needed if you need full write support | ||
| on the remapped object. | ||
@@ -225,9 +216,18 @@ ```javascript | ||
| if( old.match(/^f/ )) { | ||
| return "new:" + old; | ||
| return "new:" + old; | ||
| } else { | ||
| // ignore everything else | ||
| return undefined; | ||
| // ignore everything else | ||
| return undefined; | ||
| } | ||
| } | ||
| function reverse(new) { | ||
| // map names that start with "new:" to the old name | ||
| if( new.match(/^new:/) { | ||
| return new.substring(4); | ||
| } else { | ||
| return undefined; | ||
| } | ||
| } | ||
| var c = new Configuration(); | ||
@@ -237,3 +237,3 @@ c.set("foo",1); | ||
| var r = new RemapConfig( { mapper: mapper, original: c } ); | ||
| var r = new RemapConfig( { mapper: mapper, reverse: reverse, original: c } ); | ||
@@ -246,15 +246,6 @@ console.log( r.get('new:foo') ); | ||
| The mapper can be a function as above, or it can be a simple | ||
| java object with old values as keys and new values as corresponding | ||
| javascript object with old values as keys and new values as corresponding | ||
| values. Keys not present in the object will be mapped out of the | ||
| RemapConfig. | ||
| RemapConfig. (Also, the reverse mapping is calculated automatically.) | ||
| Not surprisingly, there are a couple of restrictions on this type of | ||
| configuration object. First, it is read only. Second, the mapper | ||
| function can show that it ignores part of the object space by | ||
| returning undefined for some values. For the rest of the values, it | ||
| must make sure to return unique new names for different old names. | ||
| Remapped objects do pass on events, and can be used as overrides or | ||
| defaults in a config container. | ||
| ## API | ||
@@ -361,3 +352,3 @@ | ||
| Generates a detailed report on the given stream (or stdout) of all of | ||
| the names and values in YAML format. | ||
| the names and values in YAML format with comments indicating sources. | ||
@@ -364,0 +355,0 @@ - writeFile( filename, format ) |
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
1
-50%148384
-0.43%711
-1.25%