|
| 1 | +# Contributing to react-compiler-tracker |
| 2 | + |
| 3 | +The following is a set of guidelines for contributing to react-compiler-tracker. Please spend several minutes reading these guidelines before you create an issue, pull request or discussion. |
| 4 | + |
| 5 | +## Code of Conduct |
| 6 | + |
| 7 | +Doist has adopted the [Contributor Covenant](https://www.contributor-covenant.org/) as its Code of Conduct, and we expect contributors to react-compiler-tracker to adhere to it. Please read [the full text](https://github.com/Doist/react-compiler-tracker/blob/main/CODE_OF_CONDUCT.md) so that you can understand what actions will and will not be tolerated. |
| 8 | + |
| 9 | +## Open Development |
| 10 | + |
| 11 | +All work on react-compiler-tracker happens directly on [GitHub](https://github.com/Doist/react-compiler-tracker). Both core team members and external contributors send pull requests that go through the same review process. |
| 12 | + |
| 13 | +## Semantic Versioning |
| 14 | + |
| 15 | +react-compiler-tracker follows [semantic versioning](https://semver.org/). We release patch versions for critical bugfixes, minor versions for new features or non-essential changes, and major versions for any breaking changes. |
| 16 | + |
| 17 | +Every significant change is documented in the [CHANGELOG.md](CHANGELOG.md) file. |
| 18 | + |
| 19 | +## Branch Organization |
| 20 | + |
| 21 | +Submit all changes directly to the [main](https://github.com/Doist/react-compiler-tracker/tree/main) branch. We don't use separate branches for development or for upcoming releases. We do our best to keep `main` in good shape, with all tests passing. |
| 22 | + |
| 23 | +## Proposing a Change |
| 24 | + |
| 25 | +If you intend to change the public API, or make any non-trivial changes to the implementation, we recommend opening a [GitHub Discussion](https://github.com/Doist/react-compiler-tracker/discussions) with the core team first. Although we welcome all contributions, this lets us reach an agreement on your proposal before you put significant effort into something that might not fit Doist product requirements. |
| 26 | + |
| 27 | +## Your First Pull Request |
| 28 | + |
| 29 | +Working on your first Pull Request? You can learn how from this free video series: |
| 30 | + |
| 31 | +- [How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github) |
| 32 | + |
| 33 | +If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don't accidentally duplicate your effort. |
| 34 | + |
| 35 | +## Project Setup |
| 36 | + |
| 37 | +Before you can contribute to the codebase, you will need to fork the react-compiler-tracker repository, and the following steps will help you hit the ground running: |
| 38 | + |
| 39 | +1. Fork the repository (click the <kbd>Fork</kbd> button at the top right of [this page](https://github.com/Doist/react-compiler-tracker)); |
| 40 | + |
| 41 | +2. Clone your fork locally; |
| 42 | + |
| 43 | +```sh |
| 44 | +git clone https://github.com/<your_github_username>/react-compiler-tracker.git |
| 45 | +cd react-compiler-tracker |
| 46 | +``` |
| 47 | + |
| 48 | +3. Install all dependencies by running `npm install`; |
| 49 | + |
| 50 | +## Development Workflow |
| 51 | + |
| 52 | +After cloning react-compiler-tracker and installing all dependencies, several commands are at your disposal: |
| 53 | + |
| 54 | +- `npm run build`: Builds the `@doist/react-compiler-tracker` package for publishing to [npm](https://www.npmjs.com/); |
| 55 | +- `npm run check`: Validates code quality and types with Biome and TypeScript; |
| 56 | +- `npm run fix`: Automatically fixes linting issues with Biome; |
| 57 | +- `npm run test`: Runs all unit tests with Vitest; |
| 58 | +- `npm run test:watch`: Runs tests in watch mode. |
| 59 | + |
| 60 | +### Release Process (core team only) |
| 61 | + |
| 62 | +The release process for react-compiler-tracker is automated with [release-please](https://github.com/googleapis/release-please). When commits following the [Conventional Commits](https://www.conventionalcommits.org/) specification are merged to `main`, release-please automatically creates or updates a release PR. When that PR is merged, a new version is published to npm. |
| 63 | + |
| 64 | +## Sending a Pull Request |
| 65 | + |
| 66 | +Pull requests are actively monitored, and only need the approval of one or more core team members. We will review your pull request and either merge it, request changes to it, or close it with an explanation. |
| 67 | + |
| 68 | +Before submitting a pull request, please take the following into consideration: |
| 69 | + |
| 70 | +- Fork [the repository](https://github.com/Doist/react-compiler-tracker) and create your branch from `main`; |
| 71 | +- Follow the [Commit Message Guidelines](#commit-message-guidelines) below; |
| 72 | +- Add tests for code that should be tested (like bug fixes); |
| 73 | +- Ensure the test suite passes with flying colours; |
| 74 | +- Do not override built-in validation and formatting checks. |
| 75 | + |
| 76 | +### Commit Message Guidelines |
| 77 | + |
| 78 | +#### Atomic Commits |
| 79 | + |
| 80 | +If possible, make [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit), which means: |
| 81 | + |
| 82 | +- A commit should not mix whitespace and/or code style changes with functional code changes; |
| 83 | +- A commit should contain exactly one self-contained functional change; |
| 84 | +- A commit should not create an inconsistent state (e.g., test errors, linting errors, partial fix, etc.). |
| 85 | + |
| 86 | +#### Commit Message Format |
| 87 | + |
| 88 | +This repository expects all commit messages to follow the [Conventional Commits Specification](https://www.conventionalcommits.org/) to automate semantic versioning and `CHANGELOG.md` generation. |
| 89 | + |
| 90 | +As a quick summary, each commit message consists of a **header**, an **optional body**, and an **optional footer**. The header has a special format that includes a **type**, an **optional scope**, and a **description**: |
| 91 | + |
| 92 | +``` |
| 93 | +<type>[optional scope]: <description> |
| 94 | +
|
| 95 | +[optional body] |
| 96 | +
|
| 97 | +[optional footer(s)] |
| 98 | +``` |
| 99 | + |
| 100 | +Commit types, such as `feat:` or `fix:`, are the only ones that will affect versioning and `CHANGELOG.md` generation, whereas commit types such as `build:`, `chore:`, `ci:`, `docs:`, `perf:`, `refactor:`, `revert:`, `style:` and `test:` will not. They are still valid, and it would be great if you could use them when appropriate. |
| 101 | + |
| 102 | +A commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section, or appends a `!` after the type/scope, introduces a breaking API change (correlating with `MAJOR` in Semantic Versioning). A breaking change can be part of commits of any _type_. |
| 103 | + |
| 104 | +## License |
| 105 | + |
| 106 | +By contributing to react-compiler-tracker, you agree that your contributions will be licensed under its [MIT license](LICENSE). |
| 107 | + |
| 108 | +## Attribution |
| 109 | + |
| 110 | +This document is based on [reactjs.org contributing guidelines](https://reactjs.org/docs/how-to-contribute.html). |
0 commit comments