Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/aliammari1/readrealm/llms.txt

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

ReadRealm welcomes contributions from developers of all skill levels. This guide walks you through everything you need to go from zero to an open pull request.
Before contributing, please read the Code of Conduct. We are committed to providing a welcoming and inspiring community.

​
Contribution flow

1

Fork and clone the repository

Fork the repository on GitHub, then clone your fork locally and add the upstream remote:
git clone https://github.com/YOUR_USERNAME/readrealm.git
cd readrealm

# Add upstream remote to stay in sync with the original repo
git remote add upstream https://github.com/aliammari1/readrealm.git
2

Create a feature branch

Always branch off the latest main. Pull upstream changes before creating a new branch:
git checkout main
git pull upstream main

git checkout -b feature/your-feature-name
3

Install dependencies

Run the first-time setup task to install all dependencies across the monorepo:
task setup
Or install each app manually:
# Backend
cd apps/api && npm ci && cd ../...

# Admin dashboard
cd apps/dashboard && flutter pub get && cd ../...
4

Make your changes

Write your code, following the code style guidelines for the platform you are working on. Run linters and formatters before committing:
task lint
task format
5

Commit your changes

Use the commit message format described below. Keep each commit focused on a single logical change.
6

Push and open a pull request

Push your feature branch to your fork and open a PR on GitHub:
git push origin feature/your-feature-name
In your PR, include a clear title, a description of what changed, a reference to any related issue, and screenshots for UI changes.

​
Commit message format

Use the following format for all commit messages: 
[TYPE] Short description (max 50 chars)

Longer explanation if needed. Reference issues with:
- Fixes #123
- Related to #456
The TYPE prefix identifies the nature of the change:
TypeWhen to use
feat:New feature
fix:Bug fix
docs:Documentation changes
style:Code style — formatting, missing semicolons, etc.
refactor:Code refactoring without behavior change
perf:Performance improvement
test:Adding or updating tests
chore:Build system, dependencies, tooling
Example: 
feat: Add batch book import from CSV

- Parse CSV file and validate data
- Show import progress dialog
- Notify user on completion
- Fixes #89

​
PR checklist

Before opening your pull request, verify each of the following:
  • Branch was created from the latest main
  • Changes have been tested locally
  • Tests have been added or updated
  • Linting passes (task lint or equivalent)
  • Code has been formatted (task format or equivalent)
  • Commit messages follow the format above
  • PR description clearly explains the changes
  • No breaking changes, or breaking changes are documented
Check open issues and pull requests before starting significant work. Opening an issue first to discuss your approach can save you time.

​
Before you start

  1. Check existing issues and PRs — Avoid duplicating work that is already in progress.
  2. Open an issue first for significant changes — Discuss your approach before investing time.
  3. Test locally — Ensure your code works before submitting.
  4. Follow the code style — Run linters and formatters for your platform.

​
Need help?

Build docs developers (and LLMs) love

Get started for freeTalk to us