2024-03-02 14:49:57 +03:00
2024-03-02 14:49:57 +03:00
2024-01-30 14:36:12 +03:00
2024-03-02 14:42:53 +03:00
2023-07-12 02:16:29 +03:00
2023-02-28 16:41:00 +03:00
2023-02-26 20:40:43 +03:00
2023-07-12 02:16:29 +03:00
2024-01-16 19:20:05 +03:00
2022-05-29 23:01:47 +03:00
2024-03-02 14:47:42 +03:00
2024-01-30 14:36:57 +03:00

quetza-logo

Quetza │ Build Status

Awesome Discord bot that performs various duties on my server.

Architecture

At its core Quetza is simply a user-client with a logger.

Modules

Modules define the features of Quetza.

🗂 The structure of a module

modules/example/
├ module.ts
├ commands/
│ ├ [command-name].ts
├ events/
│ ├ [event-name].ts
├ lib/
│ ├ [...libraries] // Including controller if exists.

module.ts

The module must have a definition file that adheres to the following interface as export.

📐 Module export interface [defined in src/lib/types.ts]

interface Module {
  name: string; // Name of the module.
  description?: string; // Description of the module.
  controller?: unknown;
  // The service orchestrating the module. (passed as third argument to command or event executor)
}

commands/[command-name].ts

Each command has to be defined in its own file, preferably named after the command itself. The client indexes the commands of each module and sends them to the Discord API.

📐 Command interface to export [defined in src/lib/types.ts]

interface Command {
  data: ApplicationCommandData; // Definition of command specifically for the Discord API.
  execute: (client: Client, interaction: CommandInteraction, controller?: unknown) => Promise<void>;
  // Function that will be called upon interaction invocation.
}

⚠️ Each command must comply with the command interaction requirements of the Discord API.

events/[event-name].ts

Events are pre-defined by the Discord API and can only have new functions bound to them by modules, despite being declared similarly to commands.

📐 Event interface to export [defined in src/lib/types.ts]

export interface Event {
  name: string;
  execute: (client: Client, eventee: unknown[], controller?: unknown) => Promise<void>;
}

✅ These can be re-defined so that they can operate independently in their own module.

lib/[...libraries] & controller

If you expand the provided module structure, it will still be a valid module. lib/ is simply a suggestion to add consistency to the codebase.

The controller is responsible for orchestrating the behaviour of your module. Imagine it like a web application service.

📘 For example, creating players for listening to music on voice channels

Build System

Quetza relies on various dependencies to function correctly. The package.json file lists the engines, toolchain, dependencies, and other metadata.

⚠️ pnpm is being used as package manager.

External Dependencies

Modules (or maybe Quetza itself) can leverage external binaries that shall be located at bin/ directory or be accessible from the environment.

🔗 Listing of extenal dependencies

Base/Module Dependency
Music yt-dlp

Shipping

Docker

Build Status

The primary method of deploying Quetza is through a Docker Image provided by the respective action.

docker run \
-e DISCORD_TOKEN=*aquired via Discord Developer Portal* \
--name quetza -d \
unknowableshade/quetza-bot:latest

From Source

Although it is possible to run it directly from the source, some additional steps are required.

  • Compile TypeScript
pnpm run build
  • Run Quetza
pnpm start

Environment

In any case, you have to provide environmental variables for bot to run.

Licence

Quetza's source code is licensed under the MIT Licence.

Notice! This does not cover 'Quetza' branding such as logo or other assets listed, as these are protected by the separate licence.

S
Description
No description provided
Readme MIT
4 MiB
0 Stars 1 Watchers 0 Forks
Languages
TypeScript 95.3%
Python 2.4%
JavaScript 1.1%
Dockerfile 0.7%
Shell 0.5%