|
| 1 | +# Contributing |
| 2 | + |
| 3 | +We'd love to accept your patches and contributions to this project. There are just a few guidelines you need to follow which are described in detail below. |
| 4 | + |
| 5 | +## How To Contribute |
| 6 | + |
| 7 | +### 1. Fork this repo |
| 8 | + |
| 9 | +You should create a fork of this project in your account and work from there. You can create a fork by clicking the fork button in GitHub. |
| 10 | + |
| 11 | +### 2. One feature, one branch |
| 12 | + |
| 13 | +Work for each new feature/issue should occur in its own branch. To create a new branch from the command line: |
| 14 | + |
| 15 | +```shell |
| 16 | +git checkout -b my-new-feature |
| 17 | +``` |
| 18 | + |
| 19 | +where "my-new-feature" describes what you're working on. |
| 20 | + |
| 21 | +### 3. Add tests for any bug fixes or new functionality |
| 22 | + |
| 23 | +All functions must be tested with a unit test. Please follow the existing convention of one exported function per file with a corresponding file to test it. Run tests using `bun test`. |
| 24 | + |
| 25 | +### 4. Check code style |
| 26 | + |
| 27 | +Before opening a pull request, ensure that you have installed all dependencies so the pre-commit hooks will run. |
| 28 | +These hooks will run ESLint according to the [.eslintrc.json](./.eslintrc.json) and style the code according to the prettier defaults. |
| 29 | + |
| 30 | +### 5. Add documentation for new or updated functionality |
| 31 | + |
| 32 | +Please review all the .md files in this project to see if they are impacted by your change and update them accordingly. |
| 33 | + |
| 34 | +### 6. Format Commits |
| 35 | + |
| 36 | +This project uses [Semantic Release](https://github.com/semantic-release/semantic-release) for versioning. As such, commits need to follow the format: `<type>(<scope>): <short summary>`. All fields are required. |
| 37 | + |
| 38 | +### 7. Submit Pull Request and describe the change |
| 39 | + |
| 40 | +Push your changes to your branch and open a pull request against the parent repo on GitHub. The project administrators will review your pull request and respond with feedback. |
| 41 | + |
| 42 | +## How Your Contribution Gets Merged |
| 43 | + |
| 44 | +Upon Pull Request submission, your code will be reviewed by the maintainers. They will confirm at least the following: |
| 45 | + |
| 46 | +- Tests run successfully (unit, coverage, integration, style). |
| 47 | +- Contribution policy has been followed. |
| 48 | + |
| 49 | +One (human) reviewer will need to sign off on your Pull Request before it can be merged. |
0 commit comments