Support multiple config for diffrent branch in one process.

[lanistor]

Add configrc.* file to read config directory;
configrc.* file can support multiple config for diffrent branch in one process.

[lorenwest]

What is this solving? Was there a discussion of this that I missed?

[lorenwest]

This breaks our Travis CI tests

[lanistor]

Sorry, it's because of using let, i had repaired this problem.
node-config is a great library, we dependent on it deeply in our projects.
But when we need deploy our project progresively, we found it cannot fit us well: we need to deploy multiple versions' code of same project in one process, then support a router to dispatch them, and each version need to have their own configuration, then we found node-config cannot do it.
Our solution
To resolve this problem, we change node-config, add a file named configrc.* to read NODE_CONFIG_DIR: when set this environment, node-config will first finding configrc.* to read NODE_CONFIG_DIR in __dirname, when not found, it will recursively find the upper level directory, until reach root directory, when found it, then use the old rule to load configuration files.
Also supply a "config" filed for merging.
Usage

USE_CONFIG_RC=true CONFIG_RC=configrc.json node server

Also support json5, js, ts, json, yaml and so on.
configrc.json

{
    "NODE_CONFIG_DIR": "./branches/a/server/config",
    "config": {
        "assetDir": "./branches/a/static",
        "serverDir": "./branches/a/server"
    }
}

Test
In ./test/14-node-configrc.js.

[markstos]

So to make sure I understand your situation: You've got a big project, one where part of it might depend on a project that uses node-config and is at version 3, and elsewhere it might depend on the same project that requires node-config, but is "version 2" of the same project, and the different versions need different configurations, correct?

This sounds a lot like #225 and #226 Have you read through those related issues?

[lanistor]

@markstos Yeah, had readed them, almost the same problem, except one difference: the submodules are the current repository itself, but different commits. So the setModuleDefaults doesn't fit, for the same commit may be main module, also may be submodule. Besides, the setModuleDefaults need to change NODE_CONFIG_DIR and clean the cache, this usage invades codes too much i think.

The usage of configrc is like this:

|-- server.js
|-- configrc.json5
    : { NODE_CONFIG_DIR: "./config" }
|-- config
    |-- default.json
    |-- production.json
|-- submodules
    |-- version_1.1.6
        |-- entry.js
        |-- config
            |-- default.json
            |-- production.json
        |-- configrc.json5
            : { NODE_CONFIG_DIR: "./submodules/version_1.1.6/config" }
        |-- node_modules
            |-- node-config
    |-- version_1.1.8
        |-- entry.js
        |-- config
            |-- default.json
            |-- production.json
        |-- configrc.json5
            : { NODE_CONFIG_DIR: "./submodules/version_1.1.8/config" }
        |-- node_modules
            |-- node-config

Each submodule has its own configurations directory, own node_modules which contains node-config, also own configrc.* file which leads NODE_CONFIG_DIR to their own configurations directory.
Then run USE_CONFIG_RC=true CONFIG_RC=configrc.json5 node server to start.
Remark: the configrc.* file can be copied into every submodule by outside respositoy.

[markstos]

I'm closing this in favor of #670, which offers a clearer vision of how to address submodule support.

I'm not sure #670 addresses having different versions of configuration for different versions of the same module, but no else but the author has expressed on this PR since 2018, so it is apparently an edge case.