Restructure bot

[lavgup]

Uses modularised plugin-based system. This makes navigating the codebase much easier as each functionality has its own folder rather than jamming it together in a few files.

If you want to implement, say, automod, it could be as simple as this:

// plugins/automod/index.ts
export default class AutomodPlugin extends Plugin {
    load(): RunPlugin {
        return new Automod(this.client);
    }
}

export class Automod extends RunPlugin {
       client: DotsimusClient;

       constructor(client: DotsimusClient) {
        super(client);
        this.client = client;

        this.client.on("messageCreate", this.onMessage.bind(this));
    }

       async onMessage(message: Message): Promise<void> {
        const violation = await analyseMessage(message);
        if (violation) await message.delete();
                // ...
      }
}

I left the sample about command, and added a ban command with button-based confirmation. Also added more rules to the ESLint config so the codebase is more consistent (includes double quotes, dangling commas and semi-colons etc.)

[lavgup]

@Jasius @BeakerThe1st I'd like to know your thoughts on this, as it is a pretty major restructure.

The reason for it is that it's a good practice to have functionalities in their own folders, it organises the codebase so it can be easily navigated (problem with watch? - go to the watch folder). The structure also allows for uniting event emitters, so all code relating to the plugin will be in one place, rather than split into multiple event files. Later on, this system can be utilised with a whitelist/blacklist so users can choose exactly what they want to run in the bot, with a simple if statement.

Please let me know if this isn't exactly the structure you had in mind, it can always be modified.

[Jasius]

Looks good to me and allows to easily isolate modules if something breaks

[lost-in-action]

I had this in mind, it's cool someone suggested it, it's a very good idea, and as you said the codebase can be easily restructured, users would even be able to whitelist or blacklist some plugins. There could also be experimental set (like which servers should have this plugin enabled for experimental testing) and more.

I'm 100% with this plugin system. Need to think more about it but how about plugins that do similar stuff (like Automod and ReportSystem for user cases), should there be an utility plugin for that?

[Jasius]

should there be an utility plugin for that?

Utility as in command to control what features are available within the server?

[lost-in-action]

should there be an utility plugin for that?

Utility as in command to control what features are available within the server?

Utility as a shared plugin that provide common classes/methods for multiple modules, because both automod and report system manage user cases stuff (creating/finding threads in the investigation channel), it should be better to reunite user case related stuff in common place. But actually I don't know if it should really be a plugin since it would only provide classes/methods, unless it have store data, or schedule events like (trivial example) if an user gets banned, archive the thread

[lavgup]

Yep, that wouldn't be a plugin. That would ideally be a /functions folder providing a React-like API (hooks) for ease of use. I saw this in the Yuudachi bot, and it looks appealing.

For example for a command, and an event, that gets a user case, a hook (e.g. getCase(x)) could be called at the top of the function which returns the case and throws if non-existent. This one-liner simplifies the code by a whole margin, one thing this PR aims to do.

[lavgup]

This PR is ready to merge, won't be making any more updates to it.