Hi,

I'm wanting to use Knub in a Discord bot I'm working for my server, we intend for the bot to eventually become open source under the GNU General Public License, however I'm noticing some conflicts on the repository vs the Node Repositories.

The GitHub repository has no explicit license, inferring that is is all rights reserved and we need to discuss a private license, however, the Node Package Manager says the project is licensed under MIT, in which case all I would need to do is state that the project uses libraries which are licensed under MIT (or relicense my project)

Please let me know what's going on and if we need to discuss something privately.

Preparation for #3

Code that caused the error:

  [...]
    overrides:
    - any:
        role: "1234"
        level: '>=10'
      config:
  [...]

Problems with the current monolithic plugin classes:

• Messy to compose
  • Mixins would require extra fiddling with types, especially if the mixins call each other
  • Splitting plugin functionality to non-class functions would require manually passing several plugin functions (with context!) as arguments to each function
• Statically analyzing e.g. commands is mostly an afterthought and only works when using the decorators that add static data to the class
• One of the original goals of Knub was that you wouldn't necessarily need to use the Plugin base class that is provided but could load any class you wanted. This is still true, but it's clearly not a well-supported workflow, and a lot of Knub functionality is only present in the base Plugin class.
• No clearly defined way to interact between plugins and define public interfaces. Public class methods on the plugin class are currently the most idiomatic way to do this, but there are several public methods in the base plugin class that shouldn't be called by other plugins (but need to be called by the plugin loader, so need to be public) and plugins might have other reasons to keep their methods public but not usable by other plugins.

Proposed solution:

• New manifest-based plugin syntax:

  export default {
    id: 'foo-bar',
  
    commands: [
      MyCommand,
      OtherCommand,
      ThirdCommand,
    ],
  
    public: {
      somePublicFn,
      secondPublicFn,
    },
  
    load({ events, config, state }) {
      // The plugin load() function is called with an object that
      // includes functions and objects for the functionality
      // previously included in the base plugin class.
      // 
      // This object is also passed to the command handlers and
      // public functions defined above.
    }
  }

• Lifecycle hooks (e.g. load()) and command handlers are both called with an object that includes plugin functionality previously included in the base class, such as event handling, config loading, etc.
• Passing around this object (or parts of it) makes composing plugins out of multiple functions easy
• Since commands are specified in the manifest, they are easy to analyze for e.g. documentation pages
• A clearly defined public interface that other plugins can use. These functions also get the object mentioned above passed to them (the calling plugin is not responsible for passing that).
• A minimal plugin would only contain an id and e.g. a load function or a command, so there's very little overhead/boilerplate to create a plugin

Rough overview of new plugin loading

• For each guild, create:
  • An event manager
    • = an event emitter that re-emits discord events that match the guild
• For each plugin, create:
  • A config loader
    • Can be used to load configs with overrides matching specific criteria
  • A plugin event manager
    • A wrapper around the guild's event manager that automatically removes listeners when the plugin is unloaded
  • A plugin command manager
    • A wrapper around knub-command-manager
    • Contains the functionality for running registered commands from a message
  • A cooldown manager
  • A lock manager
  • A state manager
• To load a plugin:

  • To load a traditional class-based plugin:

    • Pass the above to the plugin's constructor
    • Maintains backwards compatibility (except for the constructor) by using the passed loaders/managers through class methods

  • To load a function-based plugin:

    • Pass the above to the plugin's load() function as an object argument
    • The load() function returns the unload function