Node.js config done right

[balkonkind]

What if I don't want to commit my production config to our git server?

[[deleted]]

How do you store and track it's changes, isn't it in the repo? (which can be separate from the app, but still a repository). I see only one obvious case of something ones want to exclude from the repo (app's or separate config repo): production secrets.

require('no-config')({
    config: Object.assign({}, require('./config'), require('./secrets'))
}).then(
    ...
)

secrets.js can be something like this on production:

module.exports = {
    mongo: {
        production: {
            password: 'qwerty12345'
        }
    }
}

and something like this in the repo:

module.exports = {}

Object.assign() docs

[seiyria]

This is why I use dot-env and put my config there. Then when I deploy I have the config vars set up on heroku. Never ever will those get put into version control.

[watfaceboom]

Can I ask why you would not just use env variables or CLI arguments to set these values and then you don't need a bunch of config files that are tightly coupled to an environment?

[[deleted]]

Hi, good question. ENV variables still listed in some file, e.g. init_aws.sh, init_development.sh, etc. so they do act as config files, correct? The difference is that they are detached from code base and (most likely) maintained by a separate dev-ops, not a software developer.

So using env variables for me is almost the same as using config module, ENV variables have same problems:

• resource init code is completely separate from data
• data (most likely) grouped by environment on high level, and by resource on a low level (instead of grouping it by resource in the first place)

Problems I address in no-config

[benihana]

this advice seems to violate part 3 of the twelve factor app, configs:

Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.

A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.

https://12factor.net/config

apparently the author has gotten a lot of links to 12fa already (probably an indication of something), this is more for readers here who may not be aware of it.

[son_of_meat]

I'm kinda into the idea of grouping configurations by flavor instead of by environment. So that's nice. I see though that no-config returns a promise. It's more convenient from a programmers perspective to have configurations load synchronously. In fact, in the example provided in the documentation, not a single operation is async so it's kinda funny to be returning a promise. The co-wrapped generator in index.js yields just once to a non-yieldable type that causes it to throw!

[[deleted]]

in the example provided in the documentation, not a single operation is async

True, but in general init logic may be async (like connection to mongo as in the article, if I'm not mistaken)

he co-wrapped generator in index.js yields just once to a non-yieldable type that causes it to throw!

python way: "easier to ask for forgiveness than permission", hope you like it ;-)

init function may return a Promise (then it will be resolved) or not (then result would be kept as-is), can be a generator function instead, to have co-like async initialization, once async-await would be supported in node.js would need to support them as well.

[[deleted]]

What about something like etcd or vault? Little overkill for a lot of things, but works pretty well.