A what-if conversation.

What if node-config was split into two, with an inner module that I call "libconfig" here with node-config being a wrapper.

libconfig would:

• have no singletons
• handle no or minimal environment variables (and the env var names would all be defaults that could be overriden)
• Instead of reading all config file formats by default, it would read only the ones specified.
• Provide a more natural way to setup a custom parser. Right now the solution is to set an environment variable, which points to a file, which then implements an exports a custom parser. As a library, custom parsers could be passed into the constructor.

It would be a class with a constructor to which you can pass all the arguments to support all the features that node-config needs. It would then return a config object appropriately configured.

node-config could call it, get a config object back and set up its singletons and environment variables to behave as it does now.

A large, corporate code-base might call libconfig directly to set up config just how they like it and setup their own singleton, where the rest of the code base would access it as ../service/Config, but this would not interfere with other uses by submodules.

The solution would allow users to solve some pain-points they have that are not likely to be changed in node-config would be reasonable with libconfig. For example.

• Some people don't want to use local for local overrides. This could be an option to the constructor.

Where's the boundary?

There would have be some decisions about where the boundary is between what's in the interior "lib" what's what's not.

For example, would the library continue to read "custom-environment-variables.json" or would it instead take "customEnvVars" as as a constructor option? If the later, it would open the door to storing this mapping in non-JSON formats.

Config'ing the config system.

If the config library would have several options to configure, this begs the question, how to configure the config system?

The answer with NODE_CONFIG has been with up to 10 environment variables. But even those don't hold all the options users might want, like specifying which formats we include or exclude or exclude and handling "local" files.

One recommended pattern could be to use a wrapper class that calls the constructor with the preferred options and returns something useful. Depending on the need, maybe it's a singleton or maybe it's not. After that, on the original env vars would likely be needed: NODE_ENV and and NODE_APP_INSTANCE.

Future

After the split, I would expect that development on the outer wrapper known as node-config would be largely maintenance only. New users would recommended to use the library with more explicit configuration instead.

Design

I expect the new library would be written in TypeScript and would have a nice tooling experience so as you creating a new constructor in your editor, you are able to see what the options are right there and what their docs here.

The docs could provide some examples that cover typical cases.