Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Capinetta-RP/capinetta-discord-bot/llms.txt

Use this file to discover all available pages before exploring further.

Contributions to the Capinetta RP Bot System are welcome and accepted under the MIT license. Whether you’re fixing a bug, proposing a new feature, or improving documentation, this guide covers everything you need: code standards, branch conventions, the pull request process, and how to engage with maintainers.
Because this system was originally built for a specific FiveM/GTA Roleplay community (Capi Netta RP), some features are tailored to that context. When contributing new functionality, please keep changes broadly applicable so the system remains useful to other communities who adopt it.

Code of Conduct

By participating in this project, you agree to the following standards:
  • Be respectful and constructive with all contributors.
  • Accept constructive criticism gracefully.
  • Focus on what is best for the community.
  • Spam, harassment, discrimination, and inappropriate content are not tolerated.

Getting Started

1

Fork the repository

2

Clone your fork

git clone https://github.com/YOUR_USERNAME/capinetta-discord-bot.git
cd capinetta-discord-bot
3

Create a feature branch

git checkout -b feature/your-feature-name
See Branch Naming below for the full naming convention.
4

Set up your development environment

Follow the Quickstart guide to install dependencies, configure your .env file, and run npx prisma db push to sync your local database schema.
5

Make your changes

Write code that follows the Code Standards below. Keep commits focused and atomic.
6

Commit with a descriptive message

This project follows Conventional Commits:
git commit -m "feat(tickets): add emoji support to category names"
# or
git commit -m "fix(antiSpam): resolve false positives in mention detection"
Commit types: feat, fix, docs, style, refactor, perf, test, chore
7

Push and open a Pull Request

Push your branch and open a Pull Request against the main branch on GitHub. Fill in the PR template and complete the checklist below before requesting review.

Code Standards

Language and Runtime

  • Language: JavaScript (Node.js v18+). TypeScript is not required but type annotations via JSDoc comments are encouraged for complex utilities.
  • Runtime: Requires Node.js >=18.0.0 and npm >=9.0.0 as specified in package.json.

Naming and Style

// Variables and functions: camelCase
const userName = "Tullo";
function handleTicketCreation() {}

// Classes and constructors: PascalCase
class TicketManager {}

// Global constants: UPPER_SNAKE_CASE
const MAX_WARNINGS = 3;
  • Indentation: 4 spaces — no tabs.
  • Strings: Use double quotes for Discord message content; single quotes are acceptable in logic code. Be consistent within a file.

Async / Await

Always use async/await. Avoid raw .then() callback chains — they make error handling harder to reason about.
// ✅ Correct
async function handleTicket(interaction) {
    try {
        const result = await getTicketData(id);
        return result;
    } catch (error) {
        console.error("Error fetching ticket:", error);
    }
}

// ❌ Avoid
function handleTicket() {
    getTicketData(id).then(result => {
        // ...
    });
}

Error Handling

Wrap all Discord API calls and database queries in try/catch. Log errors via the project’s structured logger.js utility — never swallow exceptions silently, and never expose raw stack traces to end users.
// ✅ Validated inputs + structured error logging
if (!interaction.guild || !interaction.member) {
    return interaction.reply({
        content: "❌ Error: This command must be used in a server.",
        flags: [MessageFlags.Ephemeral]
    });
}

try {
    // command logic
} catch (error) {
    console.error("Context:", error);
    logError(client, error, "Description of what failed");
}

Discord.js Patterns

// ✅ Import only what you need
const {
    SlashCommandBuilder,
    EmbedBuilder,
    PermissionFlagsBits
} = require('discord.js');

// ✅ Always validate permissions using PermissionFlagsBits
if (!interaction.member.permissions.has(PermissionFlagsBits.Administrator)) {
    return interaction.reply("❌ Insufficient permissions.");
}

Prisma ORM

Define explicit field types and relations. Avoid using loose Json columns for structured data — create proper models with typed fields and indexes.
// ✅ Well-defined model with indexes
model Guild {
    id            String        @id
    name          String
    settings      GuildSettings?
    users         GuildUser[]
    tickets       Ticket[]
    createdAt     DateTime      @default(now())
    updatedAt     DateTime      @updatedAt

    @@index([id])
}

// ❌ Avoid loose JSON blobs
model Guild {
    id      String
    data    Json
}

No Hardcoding

All configurable values — channel IDs, role IDs, thresholds, tokens — belong in config.js sourced from .env. Never hardcode credentials or environment-specific values directly in source files.

Comments

Document non-obvious logic with inline comments. Use JSDoc blocks for exported functions:
/**
 * @file tickets/handlers.js
 * @description Handles ticket category creation and panel rendering.
 */

/**
 * Generates an HTML transcript for a closed ticket.
 * @param {import('discord.js').TextChannel} channel - The ticket channel.
 * @returns {Promise<Buffer>} The rendered HTML file buffer.
 */
async function generateTranscript(channel) {
    // ...
}

Branch Naming

PatternPurpose
feature/descriptionNew features
fix/descriptionBug fixes
docs/descriptionDocumentation-only changes
refactor/descriptionCode restructuring without behavior change

Pull Request Checklist

Before opening your PR for review, confirm all of the following:
  • Code follows the style guidelines above (camelCase, 4-space indent, async/await)
  • No hardcoded tokens, IDs, role IDs, or passwords anywhere in the diff
  • .env.example updated if any new environment variables were introduced
  • prisma/schema.prisma updated and npx prisma db push runs without errors if database schema was changed
  • Commands work as expected in a test Discord server with appropriate permissions
  • No regressions in existing commands (test common flows: tickets, warn, history, etc.)
  • PR description clearly explains what changed and why
  • Relevant documentation updated (inline comments, README section, or docs page)

Reporting Bugs

1

Check existing issues

Search GitHub Issues before opening a new one — your bug may already be tracked.
2

Reproduce on a separate branch

Confirm the bug is reproducible in isolation, not caused by a local configuration problem.
3

Open a new issue with full details

Include the following in your report:
  • Node.js version: node --version
  • Database: MariaDB/MySQL version
  • Discord.js version: from node_modules/discord.js/package.json
  • OS: e.g., Ubuntu 22.04, Windows 11
  • Error message and full stack trace
  • Steps to reproduce (numbered list)
  • Expected behavior vs actual behavior
  • Logs — paste relevant output from pm2 logs or console

Suggesting Features

Open a GitHub Discussion for feature ideas rather than a GitHub Issue. In your discussion, include:
  • Use case: what problem does this solve for an RP community?
  • Expected behavior: how should it work from the user’s perspective?
  • Discord.js API references: link relevant docs if the feature depends on a specific API
  • Alternatives considered: other approaches you thought about
You can also join the Capi Netta RP Discord server to discuss ideas with the community before writing code.

Testing

Before submitting a PR, verify your changes manually:
  • Test all affected commands in a real Discord server with appropriate bot permissions.
  • Confirm no existing functionality is broken (tickets, warn, history, etc.).
  • Validate edge cases and permission boundaries.
You can also run these checks locally:
# Validate Prisma schema
npx prisma validate

# Start the bot in development mode
npm run dev

Code Review Process

  1. The maintainer reviews the PR and may request changes or ask questions about design decisions.
  2. Once approved, the PR is merged into main.
  3. Changes are included in the next release and the CHANGELOG.md is updated.

License

This project is licensed under the MIT License — see the LICENSE file for full terms. By submitting a contribution, you agree that your code will be released under the same MIT license. Attribution to the original Capi Netta RP project is appreciated but not required by the license terms.

Build docs developers (and LLMs) love