Skip to content

Latest commit

 

History

History
188 lines (128 loc) · 6.14 KB

contributing.md

File metadata and controls

188 lines (128 loc) · 6.14 KB
Raw

Contributing to this repository

Getting started

Thank you for contributing to Rafiki 🎉

Before you begin:

Table of Contents

Types of contributions

You can contribute to Rafiki in several ways.

📣 Discussions

Discussions are where we have conversations about Rafiki.

If you would like to discuss topics about the broader ecosystem, have a new idea, or want to show off your work - join us in discussions.

🪲 Issues

We use Github issues to track tasks that contributors can help with. We haven't finalised labels yet for contributors to tackle. If you want to help with work related to an issue, please comment on the issue before starting work on it.

If you've found something that needs fixing, search open issues to see if someone else has reported the same thing. If it's something new, open an issue. We'll use the issue to have a conversation about the problem you want to fix.

🛠️ Pull requests

Feel free to fork and create a pull request on changes you think you can contribute.

The team will review your pull request as soon as possible.

Working in the rafiki repository

This project uses yarn 2. We use zero-installs which means you won't need to install dependencies when you clone the repo. This does have security implications that are checked in CI.

DO NOT use npm install, this will cause the project to spontaneously self-destruct 💥

# Clone with SSH
git clone git@github.com:coilhq/rafiki.git

# Build dependencies with install scripts
yarn install --immutable --immutable-cache

Workspaces

We use yarn workspaces to manage the monorepo. The workspace command should be used when you want to run yarn commands in specific workspaces:

# Add a package (package_name) to a single workspace(workspace_name):
yarn workspace <workspace_name> add <package_name>

# Run a script on a single workspace(workspace_name):
yarn workspace <workspace_name> <script_name>

How to share scripts between workspaces?

Any script with a colon in its name (build:foo) can be called from any workspace. Additionally, $INIT_CWD will always point to the directory running the script.

We utilize this to write shared scripts once:

# Lint in the current workspace
cd packages/backend
yarn lint # runs yarn lint:local

# OR use the workspaces command
yarn workspace backend lint # runs yarn lint:local in the packages/backend directory

Labels

We use labels to communicate the intention of issues and prs.

  • discussions: prefix denotes issues that can be converted to discussions.
  • good first issue are great issues for newcomers to take on.
  • pkg: prefix denotes issues/prs related to a specific package.
  • team: prefix lets contributors know if the issue will be done by the core team or not.
  • triage issues that the core team needs to assign labels to.
  • type: prefix denotes a specific action/category to issues/prs.

Some labels will be automatically assigned to prs.

Code quality

All the code quality tools used in the project are installed and configured at the root. This allows for consistency across the monorepo. Allows new packages to be added with minimal configuration overhead.

We try not to put config files in workspaces, unless absolutely necessary.

Linting

Eslint is used for linting.

./.eslintrc.yml # config
./.eslintignore # ignore file

Eslint config should not be overridden in any packages.

Formatting

Prettier is used for formatting.

./.prettierrc.yml # config
./.prettierignore # ignore file

Prettier config should not be overridden in any packages.

Testing

Jest is used for testing.

./jest.config.js # config used to configure projects and run all tests
./jest.config.base.js # (base jest config, imported by other packages)
./packages/*/jest.config.js # jest config file for package * (extends base.config.base.js)

Jest config at the root is intended to be a base config that should be extended by each package to suit the package's testing requirements.

Commit hooks

Husky provides git hooks.

./.husky/commit-msg # linting commit messages
./.husky/pre-commit # perform functions before committing

Commitlint is used for linting commit messages so that they conform to conventional commits.

./commitlint.config.js # config

Lint-staged is used for linting and formatting staged files on commit.

./.lintstagedrc.yml # config

https://commitlint.js.org

Language

Typescript is the chosen language.

./tsconfig.json # config

Typescript config at the root is intended to be a base config that should be extended by each package to suit the package's requirements.

CI

We use Github actions to manage our CI pipeline.

The workflows can be found in .github/workflows