wish: option to lock() the configuration, so set() commands no longer work.

[markstos]

trafficstars

set() could be useful during a configuration phase, but once the app has started, for some use cases it would be a feature if the configuration could be "locked"-- that is: read-only, immutable.

Having a 'set' method available and usable gives the impression that it could be a good idea to change a configuration value deep within the application. This could cause an 'action at a distance' bug if code elsewhere in the application continues to expect that the value from the configuration file value is a constant.

Explicitly disabling the set() method would provide an immediate to a developer that using set() after configuration is done is not the way to do things.

[shovon]

:+1:

[AdrieanKhisbe]

Interested too in that feature :)

[markstos]

Here's how the competing node-config module implements this:

The configuration starts out mutable, but once the first call to get() has been made, the configuration becomes immutable. This provides flexibility for exceptional cases like setting up a test with an alternate configuration, but also gives you the assurance that under normal conditions, the configuration is not changing underneath you.

[jcrugzz]

This is not a bad feature. I'd be ok with having a lock function implemented which causes all set commands to no-op. Thoughts @indexzero

[indexzero]

Reasonable. PR welcome.