Modules

[Avalander]

I've been thinking how to handle commands that need to do some asynchronous initialization and maybe a module system could be a good thing to have in place for that. Plus, it would provide a standard way to group commands with related functionality.

A quick draft of the API for a module could look like this:

Option A

module.exports.init = ({ client, settings, memory, store }) => {
  // Do some asynchronous initialization.
  // Return a Promise to verify that everything went well.
}

module.exports.commands = [
  // It makes sense to use modules to group related commands, so we expect this to be a list.
  (text, message, { client, settings, memory }) => {
    // Maybe we can send some things only to the `init` function, like the `client` object.
    // ...
  }
]

module.exports.shutdown = () => {
  // Do some potentially asynchronous clean up
}

Only the commands property would be required, init and shutdown can be implemented only when we need to do some initialization and/or clean up.

Option B

Another option is to have the function init return the list of commands. Than way, we could grab de client, settings and other things from there instead of having to send it as a third argument to the command. Then, the property commands would only be required when the function init is not implemented.

module.exports.init = ({ client, settings, memory, store }) => {
  // Do initialization
  // Returns either a list of commands or a Promise that resolves to a list of commands.
  return [
    (text, message) => { ... }
  ]
}

module.exports.shutdown = () => {
  // Optional function for clean up. Implementation is not required.
}

Option C

Or we might as well have the module export a factory function that would do any required initialization and return/resolve a list of commands and potentially a shutdown function.

module.exports = ({ client, settings, memory, store }) => {
  // Do initialization
  // Return or resolve
  return {
    // The property commands is required.
    commands: [
      (text, message) => { ... }
    ],
    // The property shutdown is optional.
    shutdown: () => { ... }
  }
}

[Avalander]

A couple other things we need to consider:

• How do we handle failures in module initialization? Should we start the bot without the offending module or crash?
• At some point we might want to be able to give the users instructions on how to use the module, so each module should expose some text explaining which commands are available and how to use them. Should this be yet another optional property in the module? Do we return it in the init function?

[Avalander]

@SavagePixie do you have any thoughts on this?

[arturjzapater]

• It seems to me that option C might be marginally more convenient, as all modules would then export the same regardless of what specific features they need. At least, that's what I'm leaning towards.

• Regarding how to handle failures in module initialisation, starting without the offending module (and a warning note) might be preferable? At least there'd still be some functionality.

[Avalander]

I'm also leaning more towards option C, the more I think about it. It feels a bit awkward that the commands and shutdown function are accessible before initialising the module.