|
| 1 | +# 💖 Contributing to [React Native Dropdown Picker](https://github.com/hossein-zare/react-native-dropdown-picker) |
| 2 | + |
| 3 | +Thank you for considering contributing to this library! This guide will walk you |
| 4 | +through how to do so successfully 😃 |
| 5 | + |
| 6 | +## 🤔 Overview |
| 7 | + |
| 8 | +### 🌍 General guidance |
| 9 | + |
| 10 | +You should |
| 11 | +read [GitHub's general guidance on contributing to projects](https://docs.github.com/en/get-started/quickstart/contributing-to-projects) |
| 12 | +and [guidance on collaborating with pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests). |
| 13 | + |
| 14 | +### 📄 Documentation |
| 15 | + |
| 16 | +Good and thorough documentation is important to enabling people to use a |
| 17 | +library. Therefore, it would be greatly appreciated if |
| 18 | +you [contributed to this library's documentation](https://github.com/hossein-zare/react-native-dropdown-picker-website). |
| 19 | + |
| 20 | +### 🧪 Experimenting |
| 21 | + |
| 22 | +To easily and quickly test changes before needing to add them to version |
| 23 | +control or submit them for acceptance into this library, you can |
| 24 | +use [patch-package](https://www.npmjs.com/package/patch-package). It will let |
| 25 | +you edit this library in your own project's npm dependencies to see which |
| 26 | +changes work. |
| 27 | + |
| 28 | +## 🛠️ How to contribute changes |
| 29 | + |
| 30 | +### ✅ Sensibility |
| 31 | + |
| 32 | +Read [this library's docs](https://hossein-zare.github.io/react-native-dropdown-picker-website/docs) |
| 33 | +and |
| 34 | +search [its GitHub issues](https://github.com/hossein-zare/react-native-dropdown-picker/issues) |
| 35 | +to ensure your intended changes make sense. |
| 36 | + |
| 37 | +### 🚩 Make an issue |
| 38 | + |
| 39 | +Before submitting any changes, document them |
| 40 | +in [an issue](https://github.com/hossein-zare/react-native-dropdown-picker/issues/new/choose). |
| 41 | +For example, this might be a feature request issue for the feature you will |
| 42 | +create or a bug report for the bug you will fix. If the issue already exists, |
| 43 | +e.g. a bug report for the same bug you'll fix or a feature request for the same |
| 44 | +feature you're building, skip this step. Don't make a duplicate issue. |
| 45 | + |
| 46 | +### 🍴 Forking |
| 47 | + |
| 48 | +To start work on your changes to be |
| 49 | +submitted, [fork and clone](https://docs.github.com/en/get-started/quickstart/fork-a-repo) |
| 50 | +this library. You should |
| 51 | +then [create a new branch](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging) |
| 52 | +on your fork dedicated to the changes you're making. You should |
| 53 | +read [GitHub's docs about branches](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-branches). |
| 54 | +Make sure you use a separate branch (⇒ PR) for each atomic change (e.g. adding |
| 55 | +one feature or fixing one bug) you are making. If you want to make multiple, do |
| 56 | +so in separate branches, and submit them in separate PRs. Otherwise, your PRs |
| 57 | +will bloat, and it will be hard to review, manage, and keep track of them. |
| 58 | + |
| 59 | +### 👩🏾💻 Make changes |
| 60 | + |
| 61 | +Make the changes you require to this library in your fork. Test them |
| 62 | +with `npm pack`. It will let you build this library as if for release on npm |
| 63 | +locally, so you can include it as a dependency in another npm package to test |
| 64 | +it. |
| 65 | +Read [this article](https://dev.to/scooperdev/use-npm-pack-to-test-your-packages-locally-486e) |
| 66 | +for more information on how to use `npm pack` to test your changed version of |
| 67 | +this library locally. |
| 68 | + |
| 69 | +Once you have ensured your changes work as |
| 70 | +required, [commit your changes](https://git-scm.com/docs/git-commit) |
| 71 | +and [push them to your fork](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository). |
| 72 | +Then ensure that your changes pass |
| 73 | +our [continuous integration (CI) workflow](https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration). |
| 74 | +They will show up to you |
| 75 | +as [status checks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks). |
| 76 | +To do this, you may need |
| 77 | +to [fix ESLint issues](https://eslint.org/docs/latest/use/command-line-interface#--fix) |
| 78 | +and [reformat your code with Prettier](https://prettier.io/docs/en/cli#--write). |
| 79 | + |
| 80 | +Use the script `update_reformat.sh` to automatically update this library's |
| 81 | +dependencies and reformat its code. This will help you pass our CI checks. |
| 82 | + |
| 83 | +Whenever applicable, add or update automated tests to check your changes work |
| 84 | +and that they will continue to do so in the future. You |
| 85 | +should [squash the commits you made](https://www.geeksforgeeks.org/git-squash/) |
| 86 | +containing your changes into one single commit that conforms |
| 87 | +to [the Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#summary). |
| 88 | + |
| 89 | +Ensure your changes are up-to-date with those in the `dev-5.x` (default) branch. |
| 90 | +This will mean your commit will come immediately after the last one in |
| 91 | +the `dev-5.x` (default) branch if you |
| 92 | +run [git log](https://git-scm.com/docs/git-log). |
| 93 | +Read [GitHub's guidance on keeping your pull request in sync with the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/keeping-your-pull-request-in-sync-with-the-base-branch). |
| 94 | +Doing this will prevent merge conflicts that will stop your changes being able |
| 95 | +to be merged. |
| 96 | + |
| 97 | +Once you've done all this, you're ready to submit a Pull Request (PR). |
| 98 | + |
| 99 | +### 🚀 Make a Pull Request |
| 100 | + |
| 101 | +To submit your changes for review and to have them added to this library, you |
| 102 | +must make |
| 103 | +a [pull request (PR)](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests). |
| 104 | +You will be ready to do so after following the instructions in the "Make |
| 105 | +changes" section. |
| 106 | + |
| 107 | +You can make a PR into this |
| 108 | +library [here](https://github.com/hossein-zare/react-native-dropdown-picker/compare). |
| 109 | +Ensure |
| 110 | +you [link the issue you made earlier (and any others that are relevant) to your PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#manually-linking-a-pull-request-to-an-issue-using-the-pull-request-sidebar). |
| 111 | + |
| 112 | +PRs should be made against and merged into |
| 113 | +the [`dev-5.x`](https://github.com/hossein-zare/react-native-dropdown-picker) |
| 114 | +branch, which is set as the `default` branch on GitHub. |
| 115 | + |
| 116 | +You can also make |
| 117 | +a [draft PR](https://github.blog/2019-02-14-introducing-draft-pull-requests/) |
| 118 | +before the changes are completely finished as per the "Make changes" section. |
| 119 | +This might be useful if you need feedback on your changes early on and before |
| 120 | +finalizing for merging. |
| 121 | + |
| 122 | +Once you have made a PR, you will then get feedback from the maintainers of the |
| 123 | +repo. This will help ensure your changes are ready to be merged. |
| 124 | + |
| 125 | +If required, make a separate |
| 126 | +PR [in the docs](https://github.com/hossein-zare/react-native-dropdown-picker-website) |
| 127 | +if your changes make its contents incorrect or if information regarding your |
| 128 | +changes is missing from them altogether. |
| 129 | + |
| 130 | +## 🏁 Release process |
| 131 | + |
| 132 | +Releases are currently made from |
| 133 | +the [`5.x`](https://github.com/hossein-zare/react-native-dropdown-picker/tree/5.x) |
| 134 | +branch. To make a new release, follow these steps: |
| 135 | + |
| 136 | +1. Verify the development branch has all the changes desired in the release and |
| 137 | + works well |
| 138 | +2. Make and merge a final PR into the development branch that increments the |
| 139 | + version number in `package.json` |
| 140 | +3. Make and merge a PR from the development branch to the release branch |
| 141 | +4. Using the GitHub web UI, draft a new release using the tag name `vx.x.x` |
| 142 | + (replace the `x` values as appropriate). Use the release branch as the |
| 143 | + target, with the release name being `vx.x.x` (again, with appropriate |
| 144 | + numbers in place of `x`) |
| 145 | +5. Verify in the GitHub Actions panel for the repository that `npm publish` |
| 146 | + succeeded |
0 commit comments