New store type - js, or support formatter for js

[osher]

configuration files that are written in JSON have the following limitations: 1 - they do not support comments 2 - keys require quotes 3 - they do not support expressions 4 - they do not allow dynamic generation of keys (for whatever reason)

As a result, in systems I was involved with there is a config folder in deed, but the files there are simple JS files that are loaded using the simple good old require mechanism.

So, for an over simplified example, instead of

{ "env" : "BR1"
, "domain" : "br1.mysite.com"
, "session": 
   { "cookie" : "br1sessid"
   , "expire" : 3000
   }
}

we write:

var ENV = process.args.NODE_MY_ENV || "dev"
module.exports = 
{ "env" : ENV.toUpperCase()
, "domain" : ENV + ".mysite.com" //on production ENV will be www
, "session": 
   { "cookie" : ENV + "sessid"  //TODO - yada yada bla bla
   , "expire" : 3000
   }
}

would such a store engine be welcomed here? I mean, should I even start? In any case, this store is different then file. it loads from file, but won't save, so fooling around with eval and a sandbox as implementation of parse for file formatter does not seem right to me...

Alternatively, is there a way you wish to feature to add custom stores?

If you're interested - I'd be happy to talk to somebody

[meaku]

:+1: I really like the idea and it would be great if nconf would support js-files as config-files.

[jcrugzz]

@osher Yea I would totally support this as an engine. The interesting part here is that it is so simple (as we can just use require that its own engine may be a bit too much abstraction. I don't have time to mess around with this but take a shot and submit a PR :).

[aaronshaf]

+1

[grabbou]

Another use-case -> mapping e.g. Open shift variables with project ones. Example - I am using PORT, open shift gives OPENSHIFT__PORT. Inside such a file, I just could've written "port": process.env.OPENSHIFT__PORT.

[laktak]

@osher Hjson would allow you to define your config as

{ 
  // comments
  env: BR1
  domain: br1.mysite.com
  session: 
  { 
    cookie: br1sessid
    expire: 3000
  }
}

You can load it with:

nconf.file({ file: 'file.hjson', format: require('hjson') });

This covers only your first two requirements but then it doesn't have any security issues.

[mikkotikkanen]

+1

Also, I have run into cases where you have to load something from other sources to configs or just assign same value to different section of the config, at which point you could do things like:

var config = {}`
config.thing = '123';
config.anotherthing = config.thing;

module.exports = config;

which with just pure JSON leads to error prone cases where you either A) need to have same value written twice (and make sure it stays that way) or B) need to modify the config programmatically after loading (inserting the second value).

fe. one project I'm currently working on sets the values exposed to browser that way (in order to have finer grade of control over exposed values. fe. development can expose debugging related things), ie.

config.expose_to_client = {
    thing = config.thing
}

...which is then just set to locals on express.js

[grabbou]

Well, after couple of months, it turns out it's been always possible with defaults. I've managed to get it working as expected in one of the open source projects I've been working on.

https://github.com/steida/este/blob/master/src/server/config.js

The empty nconf.get() is just a little workaround to access all the properties with dot notation, so I can write something like:

import {secret} from ../config

[mikkotikkanen]

Yes it is possible (that is the way I have hacked it myself as well) but it's not very good solution when you have multiple source files, which is one of the strengths of nconf. Basically you need to build the loading environment files & custom configs in the config files themselves. :/

[rezen]

@grabbou that does work, but ideally it would be nicer to write config modules without them having to require or know anything about the nconf.

[sscovil]

I just used node.extend to combine multiple JS config files and use that as defaults.

Example: https://gist.github.com/sscovil/d7f20a8aad807e334d622d86a247b4c7

[osher]

sorry I disappeared... the project ended up using a different config engine, so the thread lost priority. I hear all the inputs here, and it makes me want to do it, however - it falls back to a background initiative... if anybody needs it - don't wait for me, it won't happen soon