We are happy to accept your patches and contributions to this project. You just need to follow some small guidelines.
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:
tsc
Checks the code for syntax errors and unused variables and references.If you want to skip the hook, run git commit
with the --no-verify
option.
Fork & Clone the repository
Install dependencies
Copy the wrangler.example.toml
file to wrangler.toml
and fill in the necessary information
Normally, you only need to fill in the database_name
and database_id
fields.
S3 configuration is not required, but if you want to use the image upload feature, you need to fill in the S3
configuration.
client/.env.example
file to client/.env
and change the necessary configuration.Typically, you only need to fill in AVATAR
, NAME
and DESCRIPTION
.
If your database name (database_name
in wrangler.toml
) is not rin
Please modify the DB_NAME
field in scripts/dev-migrator.sh
before performing the migration
.dev.vars' file Copy
.dev.example.vars to
.dev.vars` and fill in the required informationTypically, you need to fill in the RIN_GITHUB_CLIENT_ID
and RIN_GITHUB_CLIENT_SECRET
as well as
the JWT_SECRET
fields.
In the development environment, you need to create a separate GitHub OAuth service with a callback address
of http://localhost:11498/user/github/callback
If you have changed the listening port of the server manually, please also change the port number in the callback
address.
Start the development server
For better control of the development server, you can run the client and server dev commands in two separate terminals:
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!
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.