Components

Plugins handle certain components that players can choose to add. For example, the Commander plugin makes use of Commands, which could be a class, function or object depending on the user's preference.

All built-in components are utility classes containing various special methods. Do read the documentation for more information.

Commands

Text commands are specially formatted messages that Discord users can send. Bots will then carry out tasks according to the issued command. Most commands follow this format:

<prefix><trigger> <suffix>
e.g. !help ping

Each Command component corresponds to a text command. Commands can be a class, function or object.

Commands must include:

• triggers - An array of triggers, where the first is the main trigger (i.e. command name) while the rest are aliases
• execute - A function that should accept a Container object as the first argument
• group - An optional string referencing the group of the command, defaults to 'none'

Also see: Command

Modules

Modules are classes or objects containing methods that listen to specific events the client emits.

Modules must include:

• name - A string containing the name of the middleware
• events - An object mapping an event name to a function name

Example module object:

{
  name: 'guilds:logger',
  events: {
    guildCreate: 'newGuild',
    guildDelete: 'delGuild'
  },
  newGuild: (guild) => console.log(`New guild: ${guild.name}`),
  delGuild: (guild) => console.log(`Deleted guild: ${guild.name}`)
}

Middleware

Middleware are objects that receive a Container object, insert or modify its elements, and resolve the container. Middleware are chained together and executed according to their priority number.

IMPORTANT: The purpose of middleware is to investigate the nature of a message, that is, how it's run, whether it's a command, etc. It should not be used for checking the nature of the command, such as whether a user has enough permissions to execute the message's respective text command - such checks should be done in the Command components themselves.

In other words, middleware are used to check if a user is executing a command, not if a user can execute the command.

Middleware must include:

• name - A string containing the name of the middleware
• priority - A number referencing the priority to run the middleware. A lower number means it will be run earlier.
• process - A function that should a Container object as the first argument.

Container

Containers are special objects containing properties that are passed around as a context. Among the default plugins, the Commander and Bridge plugins use them, and the Commands and Middleware components will be passed a Container as an argument, where they can modify and add properties to the container.

A default unmodified container will contain:

• msg - A message object
• client - The client instance

Optionally, it may also contain some of the built-in plugins:

• commands - A Commander instance
• modules - A Router instance
• middleware - A Bridge instance

Responder

A Responder is a helper class supplied to the 2nd argument of handle() in the built-in Command class.

Responder saves the message to reply to so no channel ID is required. It consists of several utility methods and is meant to be chained like so:

responder
.format(['emoji:information_source', 'bold'])
.file('test.jpg', buf)
.embed({ description: 'hai')
.reply('yes')

In the above example, a message will be sent to the channel where the text command is sent, with a file attachment named test.jpg, an embed with a description of hai, looking like ℹ️ | **pyraxo, hai**.

The other methods include:

• clear() - Clears all current formats, not chainable
• t() - Parses a string and replaces all {{tags}} with the corresponding tags, not chainable
• send() - Sends a normal formatted response
• reply() - Sends a response prefixed with **authorName**,
• success() - reply(), but additionally prefixed with emoji:white_check_mark
• error() - reply(), but additionally prefixed with emoji:negative_squared_check_mark
• typing() - Sends Bot is typing... to the message channel, not chainable
• dialog(dialogs, options = {}) - Creates a menu, with an array of CommandUsage objects as first argument and options object as second
  • options.tries - Number of tries for the menu if the user gives an invalid response, default to 10
  • options.time - Number of seconds for the menu to stay open, default to 60
  • options.filter - Function receiving a Eris Message object and returning a boolean
  • options.cancel - String to cancel the menu
• selection(selections, options = {}) - Creates a numbered selection menu, with an array of choices to display

CommandUsage

A CommandUsage object holds the requirements of an argument in a text command. In other words, it will be used for parsing message content arguments (split by whitespace), such as in the Command utility class (which will supply parsed arguments as container.args in handle()) or Responder class.

A CommandUsage object can hold many values, which will be used by Resolver functions to determine how to parse the argument.

Example:

[
  { name: 'member', type: 'member', optional: false, bot: true },
  { name: 'amt', displayName: 'amount', optional: true, min: 1, max: 10 }
]

// Command: +command <member> [amount]

In both CommandUsage objects, the bot, min and max keys are unique to their respective resolver, and the resolver assigned to parse the argument will use it in order to determine how to parse.

The first and second arguments will be handled using the member and amount resolvers respectively.

An example used in the Command utility class can be found here.

Resolver

Resolver objects handle the parsing of message contents and output an object mapping the arguments to the CommandUsage name.

They each contain a type string and resolve method, which takes in a string, argument options (e.g. bot, min, max as shown above) and an Eris Message object.

To see the default supported resolvers and their options, see here.