lorenwest/node-config — pull request #81 by GUI (2013-08-25 16:23:22+00:00)
Title: Fix array handling so new array values replace old ones wholesale

Previously, if you made runtime configuration changes to array values, the value would change into an object with numbered keys (instead of staying as an array).

This has been brought up a couple other times (#28, #73). I agree that how to merge arrays is a little more ambiguous, but I find the current behavior particularly confusing. If you were using arrays only in static config files, then arrays were actually already working in a wholesale replacement fashion (an array value in `hostname.json` would completely replace that same config value defined in `default.json`). It was only when you introduced runtime configuration changes into the mix that the configuration value you were interacting with suddenly changed from an array into a generic object (with numbered keys). This was due to how the configuration diff got generated for keeping track of runtime changes.

Since host specific or deployment specific config overrides were already behaving in this wholesale replacement fashion, I fixed things so live configuration changes also got treated in a similar fashion.

More generally, I'd also vote that wholesale replacement is the most intuitive approach for dealing with arrays (rather than trying to deal with additive, merge-by-value, or merge-by-index approaches). This admittedly might just be my use-cases, but a few reasons:

- The other approaches seem more complex and also introduce other issues (eg, how to reset or remove array values if additive were the default)
- If you really wanted another merging strategy, you could at least now code that yourself while making runtime changes (eg, you could manually append values to an existing array and then make a wholesale replacement with the new array).
- (For what it's worth, wholesale replacement of array values is also the strategy the popular [nconf](https://github.com/flatiron/nconf/blob/62589145f33c8abe63f0d86e0bc8f3756223fc7b/lib/nconf/stores/memory.js#L156-L162) uses and I haven't seen any complaints there about that approach)