|
| 1 | +# Contributing to TitanBot |
| 2 | + |
| 3 | +Thank you for your interest in contributing to TitanBot! This guide covers local setup, project conventions, and what we look for in pull requests. |
| 4 | + |
| 5 | +## Ways to Contribute |
| 6 | + |
| 7 | +- Bug fixes and reliability improvements |
| 8 | +- New commands or enhancements to existing features |
| 9 | +- Documentation updates |
| 10 | +- Test coverage for behavior that is easy to regress |
| 11 | + |
| 12 | +Before starting large features, open an issue or discuss in the [support server](https://discord.gg/8kJBYhTGW9) so we can align on scope and avoid duplicate work. |
| 13 | + |
| 14 | +## Getting Started |
| 15 | + |
| 16 | +### Prerequisites |
| 17 | + |
| 18 | +- **Node.js 18+** (CI uses Node 20) |
| 19 | +- **PostgreSQL** (recommended for development; the bot can fall back to in-memory storage if PostgreSQL is unavailable) |
| 20 | +- A **Discord bot application** with the intents listed in [README.md](README.md#required-bot-intents) |
| 21 | + |
| 22 | +### Local Setup |
| 23 | + |
| 24 | +1. Fork and clone the repository. |
| 25 | +2. Install dependencies: |
| 26 | + ```bash |
| 27 | + npm install |
| 28 | + ``` |
| 29 | +3. Copy the environment file and configure it: |
| 30 | + ```bash |
| 31 | + cp .env.example .env |
| 32 | + ``` |
| 33 | + At minimum, set `DISCORD_TOKEN`, `CLIENT_ID`, and `GUILD_ID` for single-server development. See [README.md](README.md#manual-installation-steps) for full configuration options. |
| 34 | +4. Verify your database setup (when using PostgreSQL): |
| 35 | + ```bash |
| 36 | + npm run migrate:check |
| 37 | + ``` |
| 38 | +5. Start the bot: |
| 39 | + ```bash |
| 40 | + npm start |
| 41 | + ``` |
| 42 | + |
| 43 | +For Docker-based setup, see [README.md](README.md#docker-deployment-recommended). |
| 44 | + |
| 45 | +## Development Workflow |
| 46 | + |
| 47 | +1. **Fork the repository** and create a branch from `main`. |
| 48 | +2. **Make focused changes** — one logical change per pull request when possible. |
| 49 | +3. **Run tests** before opening a PR (see below). |
| 50 | +4. **Open a pull request** with a clear description of what changed and why. |
| 51 | + |
| 52 | +Use descriptive branch names, for example: |
| 53 | + |
| 54 | +- `fix/ticket-panel-refresh` |
| 55 | +- `feat/economy-shop-filter` |
| 56 | +- `docs/contributing-guide` |
| 57 | + |
| 58 | +## Running Tests |
| 59 | + |
| 60 | +Tests use Node's built-in test runner: |
| 61 | + |
| 62 | +```bash |
| 63 | +npm test |
| 64 | +``` |
| 65 | + |
| 66 | +Test files live in `tests/` and follow the `*.test.js` naming pattern. When adding or changing behavior, add or update tests for: |
| 67 | + |
| 68 | +- Permission checks and command access rules |
| 69 | +- Parsing, validation, and utility logic |
| 70 | +- UI/panel builders and status helpers |
| 71 | + |
| 72 | +CI runs `npm test` on every pull request and on pushes to `main` and `master`. A separate workflow also validates database migrations against PostgreSQL when migration-related code changes. |
| 73 | + |
| 74 | +## Database & Migrations |
| 75 | + |
| 76 | +TitanBot uses PostgreSQL as its primary store. If PostgreSQL is unreachable at startup, the bot can operate in a **degraded in-memory mode** — but that mode is not suitable for production and should not be the only way you test persistence-related changes. |
| 77 | + |
| 78 | +Useful commands: |
| 79 | + |
| 80 | +| Command | Purpose | |
| 81 | +| --- | --- | |
| 82 | +| `npm run migrate` | Apply migrations | |
| 83 | +| `npm run migrate:check` | Verify schema version matches expectations | |
| 84 | +| `npm run migrate:status` | Show current migration status | |
| 85 | + |
| 86 | +If your change modifies the database schema, update the expected schema version in `.env.example` (`SCHEMA_VERSION`, `SCHEMA_VERSION_LABEL`) and ensure `npm run migrate:check` passes locally. |
| 87 | + |
| 88 | +Test features that read or write guild data with **both** PostgreSQL and the memory fallback when feasible. |
| 89 | + |
| 90 | +## Code Guidelines |
| 91 | + |
| 92 | +- **Match existing style** — ES modules (`import`/`export`), async/await, and the conventions used in neighboring files. |
| 93 | +- **Handle errors gracefully** — catch failures, log with context, and send user-friendly embed replies where appropriate. |
| 94 | +- **Avoid breaking guild isolation** — guild-specific config and data must stay scoped per server, especially when `MULTI_GUILD=true`. |
| 95 | +- **Keep changes minimal** — prefer extending existing utilities and services over duplicating logic. |
| 96 | +- **Document user-facing behavior** — update README.md when setup steps or configuration change; mention new env vars in `.env.example`. |
| 97 | + |
| 98 | +There is no ESLint config in this repo today; consistency with surrounding code is the main bar. |
| 99 | + |
| 100 | +## Pull Request Checklist |
| 101 | + |
| 102 | +In your PR description, include: |
| 103 | + |
| 104 | +- **What** changed |
| 105 | +- **Why** the change is needed |
| 106 | +- **How to test** it manually (commands, config, or env vars to set) |
| 107 | + |
| 108 | +## Reporting Issues |
| 109 | + |
| 110 | +When reporting a bug, include: |
| 111 | + |
| 112 | +- Steps to reproduce |
| 113 | +- Expected vs. actual behavior |
| 114 | +- Relevant logs (`LOG_LEVEL=debug` can help locally) |
| 115 | +- Whether you use PostgreSQL or memory fallback |
| 116 | +- Bot version / commit hash if known |
| 117 | + |
| 118 | +## License |
| 119 | + |
| 120 | +By contributing, you agree that your contributions will be licensed under the same [MIT License](LICENSE) that covers this project. |
0 commit comments