NODE_CONFIG_DIR should only affect host specific configs

[vonbirdie]

I think all but the host specific config files should ignore NODE_CONFIG_DIR. I view the non host specific config files as sane defaults set by the developer and that someone deploying your app should never touch them.

Then you can use NODE_CONFIG_DIR to point to wherever your own config files are. Especially in production where you want to easily save the config between upgrades.

[vonbirdie]

I just found setModuleDefaults. I'm not really sure of how you view the default and non host specific config files but it would be great with a clarification on what you think they're for. I think it would be great if you could load the default config from a file instead of putting it in the code and call setModuleDefaults and defaults for different environments would be great too.

[lorenwest]

I see the issue now. The NODE_CONFIG_DIR is designed to be used by the end application on a specific host. It's not designed for use by module developers.

If you are a module developer, you need a way to specify your own module's defaults. That's the reason for the setModuleDefaults() method. It's a method vs. a file because at runtime node-config doesn't know all installed modules (there may be several), so your module should call setModuleDefaults() upon loading.

I hope that answers your question.

[vonbirdie]

Oh, ok, then i misunderstood the setModuleDefaults method.

It's an application that i'm writing. What I'm trying to say is that even applications needs defaults and it's practical to store them in a file instead of calling setModuleDefaults (or handling them in some other way in the code).

When we update software at work we generally make a complete new installation in a new dir like this:

/some/path/some_software/releases/new_version/...
/some/path/some_software/releases/old_version/...
/some/path/some_software/current/... (points to currently used version)
/some/path/some_software/shared/config/

With this setup we can share the configuration (and some other stuff) between releases. The non host specific configs as far as I see them at least should still be specific for a specific release (because they are defaults set by the developer) and thus shouldn't be in the shared dir but rather in a config subdir for the release. The host specific configs I think should be shared though (because they are specified by the user).

An easy way to implement this would be by making the non host specific configs ignore the NODE_CONFIG_DIR env.

[lorenwest]

I see now what you're after. In this case I would use the setModuleDefaults method, and set your program-specific defaults using setModuleDefaults, and your deployment-specific parameters in your shared NODE_CONFIG_DIR.

You can also add machine specific or deployment specific files to your source repository so they're distributed with your code. We do it this way at work, and works well for private installations.

Changing the behavior of NODE_CONFIG_DIR is not an option as it would break existing installs. One option could be to add another environment variable pointing to program defaults vs. deployment configurations. This would allow you to do what setModuleDefault does - only in config files.

I'd like to be convinced that the added flexibility is worth the added complexity.