v1.0.0 Command Structure

[sr229]

since the inception of this project, we've used the chalda/DiscordBot layout for making commands, which is

exports.commands= [
  'xyz'
];
exports.xyz = {}

However there's limtiations on this implementation

• we can't use numbers in declaration names for export objects
• it does not encourage clean code.

so to improve this, we'll be doing a class-based approach instead of the export object approach we usually adopted.

class CommandName {
    constructor(description, usage, adminOnly) {
          description: 'nya',
          usage: '<ayn>',
          adminOnly: true;
          }
     async main() {
             await ctx.createMessage('noud is cute');
           }
}

exports.commands= CommandName;

this is usually cleaner and requires less code for subcommanding compared to the exports approach

class CommandName {
    constructor(description, usage, adminOnly) {
          description: 'nya',
          usage: '<ayn>',
          adminOnly: true;
          }
   async main() {
       await ctx.createMessage('noud is cute');
         }
   async delet() {
         this;
      }
}
exports.commands = CommandName;

[sr229]

CC @Ovyerus for your feedback

FYI for Karen maintainers, you don't need to implement this, feel free to use cogs and stuff or equivalent

[Ovyerus]

Exactly what I was thinking.

[Ovyerus]

For subcommands or commands that aren't part of the group (designated with static), we'll need to return some object so we know all the info about it.

New Proposal

const {Command, SubCommand} = require('./modules/CommandSystem'); // Or we can set `global.Command`/`global.SubCommand`.

class MyCommand {
    constructor(bot) {
        this.bot = bot; // Sets the Clara instance onto the command so we don't need to pass it to commands.
        this.description = 'The best command in the world!';
        this.owner = true;
        // ...
    }

    // Any methods called `init` will not be included in the command, and will instead be run on command setup.
    // This is equivalent to the current `exports.init = bot => {}`
    // Users can do any asynchronous setup they need in here.
    async init() {
        // ...
    }

    async subcommand() {
        return new SubCommand({
            description: 'The best subcommand in the world!',
            name: 'foo' // This is optional. By default, the name of the method will be used.
            owner: false // Will override the owner setting of the parent command if its set.
        }, async ctx => { // This is the actual function
            await ctx.createMessage('I am a banana!');
        });
    }

    static async separateCommand() {
        return new Command({
            // Some structure as SubCommand.
        }, async ctx => {
            // ...
        });
    }
}

module.exports = [MyCommand]

I was thinking of having commands extend Command, but I wouldn't know how to allow statics to be a new command, without having two separate classes ICommand and Command, although I may plan on doing this, we'll have to see.

[sr229]

@Ovyerus looks good to me, if you like, you can update the spec in example/1.x if you like that to be out final structure

One little note though, I prefer the the Command system require as a global instead to lessen LoCs