I think this is going to give you problems when users supply read-only config objects (i.e. they've used Object.freeze or something similar). I think the node-config package does this by default. Your addInheritedConfig function modifies the original configObject. That's why the other modules add themselves as config listeners (there's code in the categories module that does this too) - they'll get called after the config object has been cloned, like below.

Ah, I wasn't aware of read only config objects.

I found that I had to put some inheritance 'fixes' into the configuration validation, otherwise it rejects categories that have no directly configured appenders. I was originally just adding inheritance to the cloned config that gets passed to validation, before I realized that left the original config without any inheritance.

Would it make sense to clone the incoming readonly config, and use that clone thereafter? ie: apply inheritance, validate it, and use it for subsequent getLogger calls.

Another approach I considered was augmenting the categories object, with a getter method for appenders and level that considered inheritance, but I though it would be more efficient to just collapse inherited 'stuff' to sub-categories at startup.

Yep, the steps should be the same as on the master branch for log4js.js:

// log4js.js: line 62
configuration.configure(deepClone(configObject));

Then in configuration.js we add an extra set of listeners (addPreProcessingListeners?), and call those functions with the cloned configObject. They can modify the config before it gets validated. So categories.js would add three config listeners - one for pre-processing (apply inheritance), one for the validation rules, and one for the setup.