|
1 | | -### Tests |
| 1 | +# Contributing to react-a11y |
2 | 2 |
|
3 | | -All commits that fix bugs or add features need a test. |
| 3 | +## Setting up the workspace |
4 | 4 |
|
5 | | -`<blink>` Do not merge code without tests.`</blink>` |
| 5 | +Before you can submit a Pull Request you'll need to do the following: |
6 | 6 |
|
7 | | -### Commit Subjects for Public API Changes |
| 7 | +1. Fork the repository on GitHub |
8 | 8 |
|
9 | | -If your patch **changes the API or fixes a bug** please use one of the |
10 | | -following prefixes in your commit subject: |
| 9 | +2. Clone your fork |
11 | 10 |
|
12 | | -- `[fixed] ...` |
13 | | -- `[changed] ...` |
14 | | -- `[added] ...` |
15 | | -- `[removed] ...` |
| 11 | +```bash |
| 12 | +git clone https://github.com/<your_username>/react-a11y.git |
| 13 | +cd react-a11y |
| 14 | +``` |
16 | 15 |
|
17 | | -That ensures the subject line of your commit makes it into the |
18 | | -auto-generated changelog. Do not use these tags if your change doesn't |
19 | | -fix a bug and doesn't change the public API. |
| 16 | +3. Install for development |
20 | 17 |
|
21 | | -Commits with changed, added, or removed, should probably be reviewed by |
22 | | -another collaborator. |
| 18 | +```bash |
| 19 | +npm install |
| 20 | +``` |
23 | 21 |
|
24 | | -#### When using `[changed]` or `[removed]`... |
| 22 | +## Workflow |
25 | 23 |
|
26 | | -Please include an upgrade path with example code in the commit message. |
27 | | -If it doesn't make sense to do this, then it doesn't make sense to use |
28 | | -`[changed]` or `[removed]` :) |
| 24 | +Lint the code: |
29 | 25 |
|
30 | | -### Docs |
| 26 | +```bash |
| 27 | +npm run lint |
| 28 | +``` |
31 | 29 |
|
32 | | -Please update the docs with any API changes, the code and docs should |
33 | | -always be in sync. |
| 30 | +Run the tests: |
34 | 31 |
|
35 | | -### Development |
| 32 | +```bash |
| 33 | +npm run mocha // run tests using mocha only |
| 34 | +npm run karma // run tests using karma only |
| 35 | +npm run test // run tests using both mocha and karma |
| 36 | +``` |
36 | 37 |
|
37 | | -- `npm test` will fire up a karma test runner and watch for changes |
| 38 | +Build the code: |
38 | 39 |
|
39 | | -### Build |
| 40 | +```bash |
| 41 | +npm run build |
| 42 | +``` |
40 | 43 |
|
41 | | -Please do not include the output of `scripts/build` in your commits, we |
42 | | -only do this when we release. (Also, you probably don't need to build |
43 | | -anyway unless you are fixing something around our global build.) |
| 44 | +## Making changes |
44 | 45 |
|
| 46 | +1. Checkout a new branch and name it accordingly to what you intend to do |
| 47 | + |
| 48 | +```bash |
| 49 | +git checkout -b <branch_name> |
| 50 | +``` |
| 51 | + |
| 52 | +2. Make your intended changes, being sure to run the tests and lint the code. |
| 53 | + |
| 54 | +## Submitting a Pull Request |
| 55 | + |
| 56 | +1. Commit your changes (please make commits small and commit messages descriptive): |
| 57 | + |
| 58 | +```bash |
| 59 | + git commit -m "..." |
| 60 | +``` |
| 61 | + |
| 62 | +2. Push to _your_ github repo: |
| 63 | +```bash |
| 64 | +git push origin <branch_name> |
| 65 | +``` |
| 66 | + |
| 67 | +3. Go to the GitHub page and click "New Pull request". |
| 68 | +4. Write a good description of the change. |
| 69 | + |
| 70 | +After sending a pull request, other developers will review and discuss your change. Please address all the comments. Once everything is all right, one of the maintainers will merge your changes in. |
| 71 | + |
| 72 | +## Publishing (for maintainers) |
| 73 | +_These steps are for maintainers only and can be disregarded by contributors._ |
| 74 | + |
| 75 | +For publishing use the following workflow: |
| 76 | + |
| 77 | +1. Make sure all code changes for this new version have already been committed. |
| 78 | + |
| 79 | +2. Update the CHANGELOG.md by using the following command, double check the content and save (don't commit): |
| 80 | +```bash |
| 81 | +npm run changelog -- -t <the upcoming version> |
| 82 | +``` |
| 83 | +where `<the upcoming version>` refers to the version number that you are preparing to publish |
| 84 | + |
| 85 | +3. Update the version and publish. This is done by running _one_ of the following scripts: |
| 86 | + |
| 87 | +```bash |
| 88 | +npm version:patch # for a patch version update i.e. v1.0.0 -> v1.0.1 |
| 89 | +npm version:minor # for a minor version update i.e. v1.0.0 -> v1.1.0 |
| 90 | +npm version:major # for a major version update i.e. v.1.0.0 -> v2.0.0 |
| 91 | +``` |
| 92 | + |
| 93 | +### The publishing scripts |
| 94 | +After running one of the above `version:*` scripts the following things will take place in this order: |
| 95 | + |
| 96 | +1. the `preversion` script will run which does the following: |
| 97 | + |
| 98 | + 1. The tests will be run and the entire process will halt if they do not all pass |
| 99 | + |
| 100 | + 2. A check will be performed to validate that the `CHANGELOG.md` has been updated and it is the only uncommitted change in the repo. If this check fails the process will be halted. |
| 101 | + |
| 102 | +2. the selected `version:*` script will run which does the following: |
| 103 | + |
| 104 | + 1. The version in `package.json` will be incremented as requested (patch, minor, major). _Because the `--no-git-tag-version` flag is specified this script will not yet include tagging and committing in the github repo._ |
| 105 | + |
| 106 | +3. the `postversion` script will be run which does the following: |
| 107 | + |
| 108 | + 1. A `git commit` will be made including only the `package.json` and `CHANGELOG.md` files. It will include a commit comment in the format of: "Version $npm_package_version" |
| 109 | + |
| 110 | + 2. Performs a `git tag` in the format of "v$npm_package_version" |
| 111 | + |
| 112 | + 3. Performs a `git push` and `git push --tags` |
| 113 | + |
| 114 | + 4. Runs `npm publish` |
| 115 | + |
| 116 | + |
| 117 | +## Additional Resources |
| 118 | +* [GitHub pull request help](https://help.github.com/categories/collaborating-with-issues-and-pull-requests/) |
0 commit comments