|
| 1 | +# Contribution Guidelines |
| 2 | + |
| 3 | +Welcome to `react-intersection-observer`! I'm thrilled that you're interested in |
| 4 | +contributing. Here are some guidelines to help you get started. |
| 5 | + |
| 6 | +The codebase is written in TypeScript, and split into two packages using PNPM |
| 7 | +workspaces: |
| 8 | + |
| 9 | +- `react-intersection-observer` - The main package, which contains the |
| 10 | + `useInView` hook and the `InView` component. |
| 11 | +- `storybook` - A Storybook project that is used to develop and test the |
| 12 | + `react-intersection-observer` package. |
| 13 | + |
| 14 | +## Development |
| 15 | + |
| 16 | +Start by forking the repository, and after cloning it locally you can install |
| 17 | +the dependencies using [PNPM](https://pnpm.io/): |
| 18 | + |
| 19 | +```shell |
| 20 | +pnpm install |
| 21 | +``` |
| 22 | + |
| 23 | +Then you can start the Storybook development server with the `dev` task: |
| 24 | + |
| 25 | +```shell |
| 26 | +pnpm dev |
| 27 | +``` |
| 28 | + |
| 29 | +## Semantic Versioning |
| 30 | + |
| 31 | +`react-intersection-observer` follows Semantic Versioning 2.0 as defined at |
| 32 | +http://semver.org. This means that releases will be numbered with the following |
| 33 | +format: |
| 34 | + |
| 35 | +`<major>.<minor>.<patch>` |
| 36 | + |
| 37 | +- Breaking changes and new features will increment the major version. |
| 38 | +- Backwards-compatible enhancements will increment the minor version. |
| 39 | +- Bug fixes and documentation changes will increment the patch version. |
| 40 | + |
| 41 | +## Pull Request Process |
| 42 | + |
| 43 | +Fork the repository and create a branch for your feature/bug fix. |
| 44 | + |
| 45 | +- Add tests for your feature/bug fix. |
| 46 | +- Ensure that all tests pass before submitting your pull request. |
| 47 | +- Update the README.md file if necessary. |
| 48 | +- Ensure that your commits follow the conventions outlined in the next section. |
| 49 | + |
| 50 | +### Commit Message Conventions |
| 51 | + |
| 52 | +- We use |
| 53 | + [semantic-release](https://github.com/semantic-release/semantic-release) to |
| 54 | + manage releases automatically. To ensure that releases are automatically |
| 55 | + versioned correctly, we follow the |
| 56 | + [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) |
| 57 | + Conventions. This means that your commit messages should have the following |
| 58 | + format: |
| 59 | + |
| 60 | +`<type>: <subject>` |
| 61 | + |
| 62 | +Here's what each part of the commit message means: |
| 63 | + |
| 64 | +- `<type>`: The type of change that you're committing. Valid types include |
| 65 | + `feat` for new features, `fix` for bug fixes, `docs` for documentation |
| 66 | + changes, and `chore` for changes that don't affect the code itself (e.g. |
| 67 | + updating dependencies). |
| 68 | +- `<subject>`: A short description of the change. |
| 69 | + |
| 70 | +### Code Style |
| 71 | + |
| 72 | +`react-intersection-observer` uses [Prettier](https://prettier.io/) for code |
| 73 | +formatting. Please ensure that your changes are formatted with Prettier before |
| 74 | +submitting your pull request. |
| 75 | + |
| 76 | +### Testing |
| 77 | + |
| 78 | +`react-intersection-observer` uses [Vitest](https://vitest.dev/) for testing. |
| 79 | +Please ensure that your changes are covered by tests, and that all tests pass |
| 80 | +before submitting your pull request. |
| 81 | + |
| 82 | +You can run the tests with the `test` task: |
| 83 | + |
| 84 | +```shell |
| 85 | +pnpm test |
| 86 | +``` |
0 commit comments