More convenient module configuration system about euircbot HOT 9 OPEN

I like the parseConfig idea, but I would also like to support more format right off the bat.

Ideally, the following 4 formats would work with no parseConfig method provided:

• config.json
• config.js (basically a json file with weaker keys)
• config.yml
• config.ini (less important)

We can make this config format sorta module-manager specific. The bot should read the config file and provide it as a string to any module manager that wants it.

The module manager should then be able to add its own functionality on top of that (presumably almost all module managers will implement those formats excluding .js because that's a dumb format for non-node languages).

from euircbot.

Hmm. The way my implementation is right now, the module manager detects the existance of sirc-config.default.(extension) in the module folders. Are you saying that the core bot should be digging around in the module folder?

from euircbot.

No, the core bot absolutely shouldn't and that's a good point.

However, the config folder, like the data folder, has to be centralized. For example, two modules in different languages each might want to login to twitter, and it would make sense for them to use the same config / account via saying "I want twitter.json".

The default config is a much more iffy thing and potentially each module manager could let modules bring their own, but that could lead to duplication. I'm not sure on that one, and I'll be okay with whatever design decision you want to go with I think.

from euircbot.

Maybe instead of dropping a magic file into a module and using an exported function, we could utilize whatever package system is implemented via #30

{
    ...
    "requires-config": [
        {
            "filename": "twitter.json",
            "parser": "module/twitter" // Load the config however module/twitter does it
        },
        {
            "filename": "my-config.ini", // The filename of the config dropped into the conf folder
            "default": "sirc-default.config.ini", // If no config exists, copy this one
            "parser": "default" // Default parser resolution. Try parseConfig, if none exists, fallback on attempting to detect extension and using the default parsers
        }
    ]
    ...
}

I guess my implementation currently might be a little too module manager-specific.

from euircbot.

Looks good to me

from euircbot.

I thought about this a little more.

Why not just export the needed config files?

module.exports.configsNeeded = [
    {
        "filename": "twitter.json",
        "parser": "default"
    }
]

from euircbot.

Yeah, that's also a fine option. That was my original thought. Infer config name if it's not exported, use exported only if it is.

I don't have a strong preference regarding that vs shoving it in package.json.

from euircbot.

So look for (modulename).(predefined list of extensions) if there's no exported list, and do nothing if that file isn't there?

from euircbot.

Yup!

And then set this.config if you find the modulename one, set this.config.[name] for each named config if they're named. Something like that.

Oh, and my preferred code off the top of my head for specifying:

module.exports.configFile = "x" // x.json, x.yml, who cares. Extension optional
module.exports.run = function() {
// this.config is set to x.json's parsed contents
}


// other module
module.exports.configFiles = ['x', 'y', 'z']

module.exports.run = function() {
// this.config.x, this.config.y, and this.config.z are set
}


// another module
module.exports.name = "sirc-example"

module.exports.run = function() {
//this.config is set to the contents of sirc-example.json if it exists
}

// another, custom parser

module.exports.configFiles = [
'x', // Default parser
{
    name: 'y.ini',
    parser: function(rawIn, parsedCallback) { /* todo */ }
}];

The intent here is to make handling single config files very clean because that is the general case, while allowing multiple as needed.

from euircbot.