Stage based configuration

[dypsilon]

I would like to be able to feed the composer with different configuration options according to the current environment. This "issue" is a suggestion how it might look.

NODE_ENV Allow to control which environment is used with the NODE_ENV variable.

Formats Support different formats. Maybe use nconf for heavy lifting.

Configuration Files The default configuration should be in a file with .defaults.{format} ending, for example: manifest.defaults.json

Env specific configuration should be in a file with .{env}.{format}, example: manifest.development.json or manifest.production.json or manifest.test.json

Hierarchical Configuration Support nconf style hierarchical configuration: https://github.com/flatiron/nconf#hierarchical-configuration with the following levels:

1. argv
2. env
3. manifest.{env}.{format}
4. manifest.defaults.{format}

Nesting Nesting configuration objects should be supported. Example:

manifest.defaults.json

servers: [
        {
            port: 8000,
            options: {
                labels: ['web']
            }
        },
        {
            host: 'localhost',
            port: 8001,
            options: {
                labels: ['admin']
            }
        }
]

manifest.production.json

servers: [
        {
            port: 80
        }
]

result in the production environment

servers: [
        {
            port: 80,
            options: {
                labels: ['web']
            }
        },
        {
            host: 'localhost',
            port: 8001,
            options: {
                labels: ['admin']
            }
        }
]

[dypsilon]

Here is a nconf example I'm using right now in my applications which does exactly what I describe:

nconf.argv().env();
nconf.defaults({'NODE_ENV': 'development'});

nconf.add('envspecific', {type: 'file', file: 'configs/manifest.' + nconf.get('NODE_ENV') + '.json'});
nconf.add('envdefaults', {type: 'file', file: 'configs/manifest.defaults.json'});

var server = Hapi.createServer(nconf.get('server').host, nconf.get('server').port, nconf.get('server').options);

Hope it helps somehow.

[hueniverse]

We share the same needs and have been thinking about different ways to compose a single (virtual or not) manifest from multiple settings and sources. However, I am not convinced that this belongs in hapi. This is something that would be much better suited in another module.

I also think this is one area where multiple alternatives and ideas are needed before we can figure out if there even is one right way to do this.

I am closing this issue, and recommend that you document your experience in a blog post of gist (and link from here). We will continue to discuss this idea and will probably come out with a tool for this based on our needs in the near future.

[bernardoadc]

@dypsilon do you have the gist link? Was there a discussion about this?

[devinivy]

We achieve this through a glue manifest in the form of a confidence document with that uses dotenv to fill-out the environment.

See https://github.com/hapipal/boilerplate/blob/pal/server/manifest.js

[dypsilon]

The world changed quite a bit in those five years :) I moved on to 12 factor apps using docker.

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.