|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Reporting issues or suggesting features |
| 4 | + |
| 5 | +- First [search the open issues](https://github.com/CreativeTechGuy/recursive-proxy-mock/issues) to see if someone has already created a similar issue |
| 6 | +- If you find an existing issue, sit tight. Please do not comment just to say "+1" or "me too". |
| 7 | +- If your issue is unique, [file a new issue here](https://github.com/CreativeTechGuy/recursive-proxy-mock/issues/new/choose). |
| 8 | + |
| 9 | +## Getting started |
| 10 | + |
| 11 | +**BEFORE YOU START**: Please create an issue that documents your change before you submit a PR. |
| 12 | + |
| 13 | +1. Fork the repository |
| 14 | +1. Install dependencies by running `npm install` |
| 15 | +1. Run `npm run release` to ensure the package builds successfully without any changes |
| 16 | +1. Write the code for your feature/fix |
| 17 | +1. Write tests for the change - ensuring that every code branch is effectively tested |
| 18 | +1. Update the documentation as necessary |
| 19 | +1. Run `npm run release` before committing to ensure the code passes all tests/linters/etc |
| 20 | +1. Commit your changes following the [Commit message conventions](#commit-message-conventions) below |
| 21 | +1. Submit a PR for review |
| 22 | + |
| 23 | +## Commit message conventions |
| 24 | + |
| 25 | +We are following the Conventional Commits format as popularized by [the Angular commit format](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format). This is enforced by [commitlint](https://github.com/conventional-changelog/commitlint) and used to automatically publish new versions with [semantic-release](https://github.com/semantic-release/semantic-release). |
| 26 | + |
| 27 | +At a minimum, every commit message should include following: |
| 28 | + |
| 29 | +``` |
| 30 | +<type>: <short summary> |
| 31 | +``` |
| 32 | + |
| 33 | +You can optionally include a body or footer if there's additional information that's important to add to the commit message: |
| 34 | + |
| 35 | +``` |
| 36 | +<type>: <short summary> |
| 37 | +<BLANK LINE> |
| 38 | +<body> |
| 39 | +<BLANK LINE> |
| 40 | +<footer> |
| 41 | +``` |
| 42 | + |
| 43 | +### type |
| 44 | + |
| 45 | +Must be one of the following: |
| 46 | + |
| 47 | +- `fix`: Bug fix (PATCH version) |
| 48 | +- `perf`: Performance improvement (PATCH version) |
| 49 | +- `feat`: New feature (MINOR version) |
| 50 | +- `refactor`: Changes source code without affecting functionality in any way (no new version) |
| 51 | +- `docs`: Update documentation only (no new version) |
| 52 | +- `test`: Add/update/fix test (no new version) |
| 53 | + |
| 54 | +### short summary |
| 55 | + |
| 56 | +A brief description of the change. Use the imperative, present tense: "fix" not "fixed" nor "fixes". |
| 57 | + |
| 58 | +### body |
| 59 | + |
| 60 | +Additional information to expand on the short summary |
| 61 | + |
| 62 | +### footer |
| 63 | + |
| 64 | +If the change is a breaking change, be sure to start this section with `BREAKING CHANGE: <breaking change summary>` and go on to summarize the migration instructions. |
0 commit comments