|
| 1 | +# Contributing |
| 2 | + |
| 3 | +## Questions |
| 4 | + |
| 5 | +If you have questions about implementation details, help or support, then please use our dedicated community forum at [GitHub Discussions](https://github.com/TanStack/form/discussions) **PLEASE NOTE:** If you choose to instead open an issue for your question, your issue will be immediately closed and redirected to the forum. |
| 6 | + |
| 7 | +## Reporting Issues |
| 8 | + |
| 9 | +If you have found what you think is a bug, please [file an issue](https://github.com/TanStack/form/issues/new/choose). **PLEASE NOTE:** Issues that are identified as implementation questions or non-issues will be immediately closed and redirected to [GitHub Discussions](https://github.com/TanStack/form/discussions) |
| 10 | + |
| 11 | +## Suggesting new features |
| 12 | + |
| 13 | +If you are here to suggest a feature, first create an issue if it does not already exist. From there, we will discuss use-cases for the feature and then finally discuss how it could be implemented. |
| 14 | + |
| 15 | +## Development |
| 16 | + |
| 17 | +If you have been assigned to fix an issue or develop a new feature, please follow these steps to get started: |
| 18 | + |
| 19 | +- Fork this repository. |
| 20 | +- Install dependencies by running `$ pnpm install`. |
| 21 | + - We use [pnpm](https://pnpm.io/) v7 for package management. |
| 22 | + - We use [nvm](https://github.com/nvm-sh/nvm) to manage node versions - please make sure to use the version mentioned in `.nvmrc`. |
| 23 | +- Run development server using `pnpm run watch`. |
| 24 | +- Implement your changes and tests to files in the `src/` directory and corresponding test files. |
| 25 | +- Document your changes in the appropriate doc page. |
| 26 | +- Git stage your required changes and commit (see below commit guidelines). |
| 27 | +- Submit PR for review. |
| 28 | + |
| 29 | +### Editing the docs locally and previewing the changes |
| 30 | + |
| 31 | +The documentations for all the TanStack projects are hosted on [tanstack.com](https://tanstack.com), which is a Remix application (https://github.com/TanStack/tanstack.com). You need to run this app locally to preview your changes in the `TanStack/form` docs. |
| 32 | + |
| 33 | +> [!NOTE] |
| 34 | +> The Remix app fetches the doc pages from GitHub in production, and searches for them at `../form/docs` in development. Your local clone of `TanStack/form` needs to be in the same directory as the local clone of `TansStack/tanstack.com`. |
| 35 | +
|
| 36 | +You can follow these steps to set up the docs for local development: |
| 37 | + |
| 38 | +1. Make a new directory called `tanstack`. |
| 39 | + |
| 40 | +```sh |
| 41 | +mkdir tanstack |
| 42 | +``` |
| 43 | + |
| 44 | +2. Enter that directory and clone the [`TanStack/form`](https://github.com/TanStack/form) and [`TanStack/tanstack.com`](https://github.com/TanStack/tanstack.com) repos. |
| 45 | + |
| 46 | +```sh |
| 47 | +cd tanstack |
| 48 | +git clone [email protected]:TanStack/form.git |
| 49 | +# We probably don't need all the branches and commit history |
| 50 | +# from the `tanstack.com` repo, so let's just create a shallow |
| 51 | +# clone of the latest version of the `main` branch. |
| 52 | +# Read more about shallow clones here: |
| 53 | +# https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/#user-content-shallow-clones |
| 54 | +git clone [email protected]:TanStack/tanstack.com.git --depth=1 --single-branch --branch=main |
| 55 | +``` |
| 56 | + |
| 57 | +> [!NOTE] |
| 58 | +> Your `tanstack` directory should look like this: |
| 59 | +> |
| 60 | +> ``` |
| 61 | +> tanstack/ |
| 62 | +> | |
| 63 | +> +-- form/ (<-- this directory cannot be called anything else!) |
| 64 | +> | |
| 65 | +> +-- tanstack.com/ |
| 66 | +> ``` |
| 67 | +
|
| 68 | +3. Enter the `tanstack/tanstack.com` directory, install the dependencies and run the app in dev mode: |
| 69 | +
|
| 70 | +```sh |
| 71 | +cd tanstack.com |
| 72 | +pnpm i |
| 73 | +# The app will run on https://localhost:3000 by default |
| 74 | +pnpm dev |
| 75 | +``` |
| 76 | +
|
| 77 | +4. Now you can visit http://localhost:3000/form/latest/docs/overview in the browser and see the changes you make in `tanstack/form/docs` there. |
| 78 | + |
| 79 | +> [!WARNING] |
| 80 | +> You will need to update the `docs/config.json` file (in `TanStack/form`) if you add a new documentation page! |
| 81 | +
|
| 82 | +You can see the whole process in the screen capture below: |
| 83 | + |
| 84 | +https://github.com/fulopkovacs/form/assets/43729152/9d35a3c3-8153-4e74-9cb2-af275f7a269b |
| 85 | + |
| 86 | +### Running examples |
| 87 | + |
| 88 | +- Make sure you've installed the dependencies by running `$ pnpm install` in the repo's root directory. |
| 89 | +- If you want to run the example against your local changes, run `pnpm run watch` in the repo's root directory. Otherwise, it will be run against the latest TanStack Form release. |
| 90 | +- Run `pnpm run dev` in the selected examples' directory. |
| 91 | + |
| 92 | +#### Note on `examples/react-native` |
| 93 | + |
| 94 | +React Native example requires Expo to work. Please follow the instructions from example's README.md file to learn more. |
| 95 | + |
| 96 | +#### Note on standalone execution |
| 97 | + |
| 98 | +If you want to run an example without installing dependencies for the whole repo, just follow instructions from the example's README.md file. It will be then run against the latest TanStack Form release. |
| 99 | + |
| 100 | +## Online one-click setup |
| 101 | + |
| 102 | +You can use Gitpod (An Online Open Source VS Code like IDE which is free for Open Source) for developing online. With a single click it will start a workspace and automatically: |
| 103 | + |
| 104 | +- clone the `TanStack/form` repo. |
| 105 | +- install all the dependencies in `/` and `/docs`. |
| 106 | +- run `npm start` in the root(`/`) to Auto-build files. |
| 107 | +- run `npm run dev` in `/docs`. |
| 108 | + |
| 109 | +[](https://gitpod.io/#https://github.com/TanStack/form) |
| 110 | + |
| 111 | +## Commit message conventions |
| 112 | + |
| 113 | +`TanStack/form` is using [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines). |
| 114 | + |
| 115 | +We have very precise rules over how our git commit messages can be formatted. This leads to **more readable messages** that are easy to follow when looking through the **project history**. |
| 116 | + |
| 117 | +### Commit Message Format |
| 118 | + |
| 119 | +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special |
| 120 | +format that includes a **type**, a **scope** and a **subject**: |
| 121 | + |
| 122 | +``` |
| 123 | +<type>(<scope>): <subject> |
| 124 | +<BLANK LINE> |
| 125 | +<body> |
| 126 | +<BLANK LINE> |
| 127 | +<footer> |
| 128 | +``` |
| 129 | + |
| 130 | +The **header** is mandatory and the **scope** of the header is optional. |
| 131 | + |
| 132 | +Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools. |
| 133 | + |
| 134 | +### Type |
| 135 | + |
| 136 | +Must be one of the following: |
| 137 | + |
| 138 | +- **feat**: A new feature |
| 139 | +- **fix**: A bug fix |
| 140 | +- **docs**: Documentation only changes |
| 141 | +- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing |
| 142 | + semi-colons, etc) |
| 143 | +- **refactor**: A code change that neither fixes a bug nor adds a feature |
| 144 | +- **perf**: A code change that improves performance |
| 145 | +- **test**: Adding missing or correcting existing tests |
| 146 | +- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation |
| 147 | + generation |
| 148 | + |
| 149 | +### Scope |
| 150 | + |
| 151 | +The scope could be anything specifying place of the commit change. For example `useForm`, `useMutation` etc... |
| 152 | + |
| 153 | +You can use `*` when the change affects more than a single scope. |
| 154 | + |
| 155 | +### Subject |
| 156 | + |
| 157 | +The subject contains succinct description of the change: |
| 158 | + |
| 159 | +- use the imperative, present tense: "change" not "changed" nor "changes" |
| 160 | +- don't capitalize first letter |
| 161 | +- no dot (.) at the end |
| 162 | + |
| 163 | +### Body |
| 164 | + |
| 165 | +Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior. |
| 166 | + |
| 167 | +### Footer |
| 168 | + |
| 169 | +The footer should contain any information about **Breaking Changes** and is also the place to [reference GitHub issues that this commit closes](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue). |
| 170 | + |
| 171 | +**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this. |
| 172 | + |
| 173 | +### Example |
| 174 | + |
| 175 | +Here is an example of the release type that will be done based on a commit messages: |
| 176 | + |
| 177 | +| Commit message | Release type | |
| 178 | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------- | |
| 179 | +| `fix(pencil): stop graphite breaking when too much pressure applied` | Patch Release | |
| 180 | +| `feat(pencil): add 'graphiteWidth' option` | ~~Minor~~ Feature Release | |
| 181 | +| `perf(pencil): remove graphiteWidth option`<br><br>`BREAKING CHANGE: The graphiteWidth option has been removed.`<br>`The default graphite width of 10mm is always used for performance reasons.` | ~~Major~~ Breaking Release | |
| 182 | + |
| 183 | +### Revert |
| 184 | + |
| 185 | +If the commit reverts a previous commit, it should begin with `revert:`, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted. |
| 186 | + |
| 187 | +## Pull requests |
| 188 | + |
| 189 | +Maintainers merge pull requests by squashing all commits and editing the commit message if necessary using the GitHub user interface. |
| 190 | + |
| 191 | +Use an appropriate commit type. Be especially careful with breaking changes. |
| 192 | + |
| 193 | +## Releases |
| 194 | + |
| 195 | +For each new commit added to `main` with `git push` or by merging a pull request or merging from another branch, a GitHub action is triggered and runs the `semantic-release` command to make a release if there are codebase changes since the last release that affect the package functionalities. |
0 commit comments