Contribute to Rin
We are happy to accept your patches and contributions to this project. You just need to follow some small guidelines.
Commit-msg hooks
We have a sample commit-msg hook in scripts/commit-msg.sh. Please run the following command to set it up:
On Windows, copy the commit-msg.sh file directly to .git/hooks/commit-msg.
This will run the following checks before each commit:
- Type checking -
bun run checkvalidates TypeScript types across all packages - Linting - checks code formatting and style
- Commit message format - verifies the commit message starts with one of:
feat|chore|fix|docs|ci|style|test|pref
The hook also runs tests. Make sure all tests pass before committing:
If you want to skip the hook (not recommended), run git commit with the --no-verify option.
Setting up your development environment
-
Fork & Clone the repository
-
Install dependencies
-
Fill in the required configuration in
.env.localfile.
Typically, you only need to fill in AVATAR, NAME and DESCRIPTION.
For GitHub OAuth, you need to create a separate OAuth App with a callback address of http://localhost:11498/user/github/callback
- Run the setup script to generate configuration files
This will automatically generate wrangler.toml and .dev.vars files based on your .env.local configuration.
- Perform the database migration
- (Optional) Configure S3/R2 for image upload
If you want to use the image upload feature, fill in the S3 configuration in .env.local:
S3_ENDPOINTS3_BUCKETS3_ACCESS_KEY_IDS3_SECRET_ACCESS_KEY
-
Start the development server
-
For better control of the development server, you can run the client and server dev commands in two separate terminals:
Testing Requirements
Before submitting a pull request, please ensure all tests pass:
Adding Tests for New Features
When adding new API endpoints:
- Define types in
packages/api/src/types.ts(shared between client and server) - Add server tests in
server/src/**/__tests__/*.test.ts - Add client tests in
client/src/**/__tests__/*.test.tsif applicable
Committing Changes
-
for simple patches, they can usually be reviewed within 10 minutes during the day in the UTC+8 time zone. 2.
-
Do not force push minor changes after the PR is ready for review. Doing so forces maintainers to re-read your entire PR, which delays the review process. 3.
-
Always keep the CI green.
-
If the CI fails on your PR, do not push it. Even if you don't think it's the patch's fault. If something else is breaking the CI, help fix the root cause before you push.
Start writing code happily!
Code review
All commits, including those from project members, need to be reviewed. We use GitHub pull requests for this purpose. For more information on using pull requests, see the GitHub Help.