|
| 1 | +# algoliasearch contributing guide |
| 2 | + |
| 3 | +Hello and welcome to the contributing guide for algoliasearch. Thanks for considering participating in our project 🙇 |
| 4 | + |
| 5 | +If this guide does not contain what you are looking for and thus prevents you from contributing, don't hesitate to leave a message on the [community forum](https://discourse.algolia.com/) or to [open an issue](https://github.com/algolia/algoliasearch-client-javascript/issues). |
| 6 | + |
| 7 | +## Reporting an issue |
| 8 | + |
| 9 | +Opening an issue is very effective way to contribute because many users might also be impacted. We'll make sure to fix it quickly if it's technically feasible and doesn't have important side effects for other users. |
| 10 | + |
| 11 | +Before reporting an issue, first check that there is not an already open issue for the same topic using the [issues page](https://github.com/algolia/algoliasearch-client-javascript/issues). Don't hesitate to thumb up an issue that corresponds to the problem you have. |
| 12 | + |
| 13 | +Another element that will help us go faster at solving the issue is to provide a reproducible test case. |
| 14 | + |
| 15 | +## The code contribution process |
| 16 | + |
| 17 | +algoliasearch is developed in TypeScript. For any code contribution, you need to: |
| 18 | + |
| 19 | +- Fork and clone the project |
| 20 | +- Create a new branch for what you want to solve (fix/_issue-number_, feat/_name-of-the-feature_) |
| 21 | +- Make your changes |
| 22 | +- Open a pull request |
| 23 | + |
| 24 | +Depending on what you're working on, you might consider different [base branches](#branch-organization). |
| 25 | + |
| 26 | +Then: |
| 27 | + |
| 28 | +- Peer review of the pull request (by at least one of the core contributors) |
| 29 | +- Automatic checks (tests, [commits](#commit-conventions), [linters](#linting)) |
| 30 | +- When everything is green, your contribution is merged 🚀 |
| 31 | + |
| 32 | +## Commit conventions |
| 33 | + |
| 34 | +This project follows the [conventional changelog](https://conventionalcommits.org/) approach. This means that all commit messages should be formatted using the following scheme: |
| 35 | + |
| 36 | +``` |
| 37 | +type(scope): description |
| 38 | +``` |
| 39 | + |
| 40 | +In most cases, we use the following types: |
| 41 | + |
| 42 | +- `fix`: for any resolution of an issue (identified or not) |
| 43 | +- `feat`: for any new feature |
| 44 | +- `refactor`: for any code change that neither adds a feature nor fixes an issue |
| 45 | +- `docs`: for any documentation change or addition |
| 46 | +- `chore`: for anything that is not related to the library itself (doc, tooling) |
| 47 | + |
| 48 | +Even though the scope is optional, we try to fill it in as it helps us better understand the impact of a change. We either use the name of the widget/connector/component impacted or we use impact topic (e.g. `docs`, `tooling`, `deps`, `ci`). |
| 49 | + |
| 50 | +Finally, if your work is based on an issue on GitHub, please add in the body of the commit message "fix #1234" if it solves the issue #1234 (read "[Closing issues using keywords](https://help.github.com/en/articles/closing-issues-using-keywords)"). |
| 51 | + |
| 52 | +Some examples of valid commit messages (used as first lines): |
| 53 | + |
| 54 | +> - fix(searchbox): increase magnifying glass size |
| 55 | +> - chore(deps): update dependency rollup-plugin-babel to v3.0.7 |
| 56 | +> - fix(connectRefinementList): set default value for limit |
| 57 | +> - chore: reword contributions guides |
| 58 | +
|
| 59 | +## Branch organization |
| 60 | + |
| 61 | +The project is based on the classic GitHub flow: |
| 62 | + |
| 63 | +- `master` for the current version being worked on – Pull requests for bugs and feature related to the current major version should be created against this branch |
| 64 | +- `vX` for each major version (`X` being a number) – Pull requests for critical bug fixes should be created against this branch |
| 65 | + |
| 66 | +Most of the time, your pull requests should target the `master` branch. |
| 67 | + |
| 68 | +_Note that no new features will be developed or backported for the `vX` branches._ |
| 69 | + |
| 70 | +## Requirements |
| 71 | + |
| 72 | +To run this project, you will need: |
| 73 | + |
| 74 | +- Node.js ≥ 12 (current stable version) – [nvm](https://github.com/creationix/nvm#install-script) is recommended |
| 75 | +- [Yarn](https://yarnpkg.com) |
| 76 | + |
| 77 | +## Linting |
| 78 | + |
| 79 | +Linters are static checkers for code. They help us maintain a consistent code base. They are used for JavaScript and TypeScript files. |
| 80 | + |
| 81 | +If your editor support them, then you will see the errors directly there. You can also run them using your command line: |
| 82 | + |
| 83 | +```sh |
| 84 | +yarn lint |
| 85 | +``` |
| 86 | + |
| 87 | +TypeScript files are validated using a combination of [Prettier](https://github.com/prettier/prettier) (strict syntax form) and [ESLint](https://github.com/eslint/eslint) rules (for common mistakes and patterns). We also use [API extractor](https://api-extractor.com) to validate the correct exported types. |
| 88 | + |
| 89 | +## Release |
| 90 | + |
| 91 | +### Main version |
| 92 | + |
| 93 | +To release a stable version, go on `master` (`git checkout master`) and use: |
| 94 | + |
| 95 | +```sh |
| 96 | +npm run release |
| 97 | +``` |
| 98 | + |
| 99 | +If you're part of the Algolia team, you can read more details [here](https://github.com/algolia/doc-api-clients-squad/blob/master/release/javascript-v4.md) |
0 commit comments