Contributing Guidelines

Issue Creation

Anyone may create tickets for any bugs or features. Make sure the appropriate templates are used and as much detail is given so that the developer picking it up (might be you!) has enough background.

Please create it on the project board

Branch names

Apart from development not related to any issue, create a branch and name it as the following: <issue-number>-<relevant-name>. Note: keep the name appropriate to the issue (exceptions are made for super funny names).

recommended workflow for creating a new branch:

1. git checkout master
2. git pull
3. git checkout -b <branch name>

Pull requests

Changes to master made must be done through a pull request (this is enforced). This is so we can run required workflows that ensure overall health of tests and code style and also so that critical errors introduced by changes can be reverted. ONE approval is required so please use your best judgement and know that it is in your best interest to seek reviews where possible.

Code review

Anyone is welcome (and encouraged) to review code. However, be mindful of the following:

• Be respectful
• Do not change request for nits (small non-breaking suggestions)

Merging

It is the best idea for the feature lead (the one who did most of the work on a PR) to merge the PR, as merge credit makes you the first contact about the changes introduced. In other words, you'll be blamed first if something goes wrong 😄

Testing

Client

Anything that renders on the screen needs to be developed using Storybook. This is so we can build modular components and aren't bogged down by side effects and a slow dev loop of running the whole page. This can be done by creating files with the *.story.tsx naming scheme. For an example of how to write a story (taken from official docs)

import type { Meta, StoryObj } from '@storybook/react';

import { YourComponent } from './YourComponent';

//👇 This default export determines where your story goes in the story list
const meta: Meta<typeof YourComponent> = {
  component: YourComponent,
};

export default meta;
type Story = StoryObj<typeof YourComponent>;

export const FirstStory: Story = {
  args: {
    //👇 The args you need here will depend on your component
  },
};

Server

Unit tests need to be written for most logic that does not involve data fetching

Integration tests should generally be written for:

• Services in the business layer
• Services in the data layer

Super Optional: It is also recommended to write tests for API endpoints using supertest (time consuming).

Make sure all tests follow the *.test.ts* naming scheme. Mocks should use the *.mock.ts naming scheme.

Generated files merge conflicts

I would suggest (someone could make a script):

1. git fetch origin master:master (update master to latest)
2. git merge master
3. Run codegen commands
4. git commit -a -m "fix merge conflicts"
5. Push

Packages (important)

Make sure that you install the packages in the appropriate workspace and DO NOT use npm to install. Refer to onboarding.

Useful git commands

• git checkout <branch> <file-path> to restore a file to the version on the specified branch
• git reset --hard head<~N> if you messed up completely and want to start again from N commits back (WILL DESTROY ALL YOUR CURRENT WORK)
• git reset --soft head<~N> if you messed up your commits and want to keep your work but go back N commits
• git merge origin master if you want to merge in master without checking out master
• git commit -a -m "<message>" --no-verify to skip pre commit checks (note: only use if you aren't going to be pushing anytime soon)
• git checkout -b <branch-name> create and checkout branch
• git branch -d <branch-name> deletes a branch locally
• git remote prune origin updates and removes deleted remote branches (the ones on this repo)