peerigon / dynamic-config Goto Github PK

View Code? Open in Web Editor NEW

14.0 13.0 3.0 47 KB

Loads configuration files depending on the given env

License: MIT License

JavaScript 100.00%

configuration argv javascript env

dynamic-config's Introduction

dynamic-config

Dynamic configuration files

Loads configuration files depending on:

argv: node app.js --env production
env: export NODE_ENV=production; node app.js

Expects a .js file as config so you can add dynamic content.

Installation

npm install dynamic-config --save

Options

defaultEnv: string = "develop"

Define which env should be set as default.

log: Function

Calls this function to log information about the path/env resolution.

envName: string = "env"

The argument/env variable name we expect.

Example

// config/index.js

const DynamicConfig = require("dynamic-config");
const dynamicConfig = new DynamicConfig({
    defaultEnv: "develop",
    log: console.log
});

module.exports = dynamicConfig.load(__dirname, "config.js");

// config/develop/config.js

module.exports = {
    whereami: "develop"
}

// app.js
const config = require("./config");

console.log(config);

node app.js

{ whereami: 'develop' }

// Set environment via args
node app.js --env prod

{ whereami: 'prod' }

// Set environment via env
export env=stage; node app.js

{ whereami: 'stage' }

Plugins

extend

These plugins allow you to override specific config fields by applying them via env, argv or a separate local config file.

const dynamicConfig = new (require("dynamic-config"))();

// extend from env
dynamicConfig.use(require("dynamic-config/plugins/extend/env"));

// extend from file
dynamicConfig.use(require("dynamic-config/plugins/extend/file"));

// extend from argv
dynamicConfig.use(require("dynamic-config/plugins/extend/argv"));

module.exports = dynamicConfig.load(__dirname, "config.js");

Hint: The order in which the plugins are applied is important. In the above code snippet, config fields defined via arguments would override their counterparts from an override file, which itself overrides fields from environment variables. This is probably a suitable order for most projects.

node app.js

{ name: 'superApp', port: 9000 }

// Overwrite via argv
node app.js --port 80
// ... or ...
node app.js --port=80

{ name: 'superApp', port: 80 }

// Overwrite via env
export port=90 node app.js

{ name: 'superApp', port: 90 }

// Order matters...
export port=90; node app.js --port 80

{ name: 'superApp', port: 80 }

Extend via file

Create a file named the same as your config, but contains .local in front of the extension, like config.js becomes config.local.js.

In the config extension file you can define any subset of the object, that is defined in the main config and it would overwrite the corresponding value. Both configs are merged via deep-assign.

// config.js
module.exports = {
    a: 1,
    b: {
        c: "c",
        d: 2
    },
    e: 3
}

// config.local.js
module.exports = {
    e: "e",
    b: {
        d: "d"
    }
}

// result
{
    a: 1,
    b: {
        c: "c",
        d: "d"
    },
    e: "e"
}

dynamic-config's People

Contributors

Stargazers

Watchers

Forkers

benurb flootr isabella232

dynamic-config's Issues

Should accept NODE_ENV for setting the env

resolvedConfigPath removed - Intended?

Hey guys,

if I'm annoying you just tell me, but I found a little regression with v1.0.0. resolvedConfigPath was removed. The thing is, that sometimes you need to know the filename of the config, that was loaded. With the file extension plugin this becomes even more interesting. What do you think about a method like getResolvedPaths() which returns an array like this if only the "main" config file was loaded:
["/some/folder/config/staging/config.js"]
And something like this if an overwrite file was loaded
["/some/folder/config/staging/config.js", "/some/folder/config/staging/config.local.js"]

One use case might be to check for getResolvedPaths().slice(-1).indexOf(".local") >= 0 to check if the config was successfully overwritten.

What do you think about that? For my use case it would be useful, but I'm not the center of the universe 😉

Ben

Enhancement: Local config

Hello there!

I don't know if you want this behavior in dynamic-config, but for our use case it would be a huge improvement to be able to use local configs.

Explanation:
Let's assume you have a config.js with the following content:

module.exports = {
  "path": "/etc/blubb.conf"
  "log": {
    "level": "debug"
  }
  "a lot of": "other stuff"
};

This file is under version control and fits for most of your systems. But there is a specific configuration on a server/dev machine/whatsoever that just needs a tiny bit of the config changed. In this case I would propose a config.local.js with only the specific changes. For example for the config above:

module.exports = {
  "path": "/home/benurb/blubb.conf"
};

This would make it a lot easier to have dev/local configurations without messing around with the base configuration.
What do you think about it? If you like it I can create a PR ofc 😄

Ben

Set NODE_ENV

I think, we should set NODE_ENV according to env. It is the node.js de-facto standard and can even impact performance.

Shared state causes side effects across modules

Hey guys,

currently there is a major problem with dynamic-config, because you cannot create an instance of the config loader. So when using npm >= 2 and dynamic-config can be deduped, you will end up with modules sharing the same dynamic-config instance. That means they are overriding each others plugin settings.

Example:
module a uses dynamic-config like this:

var dynamicConfig = require("dynamic-config");
dynamicConfig.use(require("dynamic-config/plugins/extend/env"));
module.exports = dynamicConfig(__dirname, "config.js");

module b uses dynamic-config like this:

var dynamicConfig = require("dynamic-config");
module.exports = dynamicConfig(__dirname, "config.js");

Now it depends on the order:
If module a is loaded before module b you will be able to overwrite configs of both modules via environment variables. This is not intended.
If module b is loaded before module a you will only be able to overwrite configs of module a. This is the intended effect.

This problem is even worse with the file extend plugin:
Module a:

var dynamicConfig = require("dynamic-config");
dynamicConfig.use(require("dynamic-config/plugins/extend/file"));
module.exports = dynamicConfig(__dirname, "config.js");

Module b:

var dynamicConfig = require("dynamic-config");
dynamicConfig.use(require("dynamic-config/plugins/extend/file"), {
  suffix: ".test"
});
module.exports = dynamicConfig(__dirname, "config.js");

If module a is loaded before module b dynamic-config will look for a config.local.js file in both modules, because .local is the default suffix. This is not correct behavior.
If module b is loaded before module a dynamic-config will look for a config.test.js file in both modules. This is also not correct. It seems plugins can only be registered once.

In my opinion it should be possible to create an instance of dynamic-config to be able to maintain the plugin configuration the developer wanted to use. I can create a PR, but wanted to ask for your opinion first 😄

Ben

Update:
Possible code example for the proposed change:

var dynamicConfig = require("dynamic-config").createInstance();

This can probably be implemented as a backwards compatible change.

Of course something like this would be fine, too, but is a breaking change ofc:

var dynamicConfig = new (require("dynamic-config"))();

customEnv

@Vispercept can you describe why you want a customEnv?

I'm thinking of handling it the same way as defaultEnv so we'd have something like envArgumentName which is env by default and can be changed to whatever you like.

It should be applied on reading from argv and env if you change it so the behavior is consistent.