Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: update CONTRIBUTING.md #2935

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
Open
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
105 changes: 61 additions & 44 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,68 +1,85 @@
# Contributing

## Reporting Issues
## General guideline

### Reporting issues
sukvvon marked this conversation as resolved.
Show resolved Hide resolved

If you have found what you think is a bug, please [start a discussion](https://github.com/pmndrs/jotai/discussions/new).
sukvvon marked this conversation as resolved.
Show resolved Hide resolved

Also for usage questions, please [start a discussion](https://github.com/pmndrs/jotai/discussions/new).
For any usage questions, please [start a discussion](https://github.com/pmndrs/jotai/discussions/new).
sukvvon marked this conversation as resolved.
Show resolved Hide resolved

## Suggesting new features
### Suggesting new features

If you are here to suggest a feature, first [start a discussion](https://github.com/pmndrs/jotai/discussions/new) 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.
sukvvon marked this conversation as resolved.
Show resolved Hide resolved

## Development guide
### Pull requests

If you would like to contribute by fixing an open issue or developing a new feature you can use this suggested workflow:
Please try to keep your pull request focused in scope and avoid including unrelated commits.

### General
After you have submitted your pull request, we'll try to get back to you as soon as possible. We may suggest some changes or request improvements, therefore, please check ✅ ["Allow edits from maintainers"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) on your PR

1. Fork this repository
2. Create a new feature branch based off the `main` branch
3. Follow the [Core lib](#core-lib) and/or the [docs](#docs) guide below and come back to this once done
4. Run `pnpm run prettier` to format the code
5. Git stage your required changes and commit (review the commit guidelines below)
6. Submit the PR for review
### Committing

### Core lib
We are applying [conventional commit spec](https://www.conventionalcommits.org/en/v1.0.0/) here. In short, that means a commit has to be one of the following types:

1. Install dependencies by running `pnpm install`.
2. Create failing tests for your fix or new feature in the `tests` folder
3. Implement your changes
4. Build the library `pnpm run build` _(Pro-tip: `pnpm run build-watch` runs the build in watch mode)_
5. Run the tests and ensure that they pass.
6. You can use `pnpm link` or `yalc` to sym-link this package and test it locally on your own project. Alternatively, you may use CodeSandbox CI's canary releases to test the changes in your own project (requires a PR to be created first)
7. Follow step 4 and onwards from the [general](#general) guide above to bring it to the finish line
Your commit type must be one of the following:

### Docs
- **feat**: A new feature.
- **fix**: A bug fix.
- **refactor**: A code change that neither fixes a bug nor adds a feature.
- **chore**: Changes to the build process, configuration, dependencies, CI/CD pipelines, or other auxiliary tools and libraries.
- **docs**: Documentation-only changes.
- **test**: Adding missing or correcting existing tests.
- **style**: Changes that do not affect the meaning of the code (e.g., formatting, whitespace, missing semicolons).
sukvvon marked this conversation as resolved.
Show resolved Hide resolved

1. Navigate to the `website` folder. Eg. `cd website`
2. Install dependencies by running `pnpm` in the `website` folder
3. Run `pnpm dev` to start the dev server
4. Navigate to [`http://localhost:9000`](http://localhost:9000) to view the docs
5. Navigate to the `docs` folder and make necessary changes to the docs
6. Add your changes to the docs and see them live reloaded in the browser
7. Follow step 4 and onwards from the [general](#general) guide above to bring it to the finish line
If you are unfamiliar with the usage of conventional commits,
the short version is to simply specify the type as a first word,
and follow it with a colon and a space, then start your message
from a lowercase letter, like this:

### Type
```
feat: add a 'atomWithStorage' type support
sukvvon marked this conversation as resolved.
Show resolved Hide resolved
```

We follow the [conventional commit spec](https://www.conventionalcommits.org/en/v1.0.0/) for our commit messages. Please review the spec for more details.
You can also specify the scope of the commit in the parentheses after a type:

Your commit type must be one of the following:
```
fix(react): change the 'useAtom' parameter type
sukvvon marked this conversation as resolved.
Show resolved Hide resolved
```

- **build**: Changes that affect the build system or external dependencies (example scopes: pnpm, npm, rollup, etc.)
- **ci**: Changes to our CI configuration files and scripts (example scopes: GitHub Actions)
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- **test**: Adding missing tests or correcting existing tests
## Jotai guideline

## Pull requests
### Development

Please try to keep your pull request focused in scope and avoid including unrelated commits.
If you would like to contribute by fixing an open issue or developing a new feature you can use this suggested workflow:

After you have submitted your pull request, we'll try to get back to you as soon as possible. We may suggest some changes or request improvements, therefore, please check ✅ ["Allow edits from maintainers"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) on your PR
#### General

Thank you for contributing!
1. Fork this repository
2. Create a new feature branch based off the `main` branch
3. Follow the [Core](#Core) and/or the [Documentation](#Documentation) guide below and come back to this once done
4. Run `pnpm run fix:format` to format the code
5. Git stage your required changes and commit (review the commit guidelines below)
6. Submit the PR for review

##### Core

1. Install dependencies by running `pnpm install`.
2. Create failing tests for your fix or new feature in the [`tests`](./tests/) folder. (e.g., `cd tests`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never done cd tests. Do you do it?

Copy link
Contributor Author

@sukvvon sukvvon Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dai-shi

Create failing tests for your fix or new feature

The existing document already specifies performing tasks like the one mentioned above, and since the test path is also mentioned in the document, I added the cd tests command. Would you like me to remove the cd tests command?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I assume most devs open tests/* files from the project root.

Copy link
Contributor Author

@sukvvon sukvvon Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dai-shi Yeah, so i added introducing about how to move tests folder from project root.

Copy link
Contributor Author

@sukvvon sukvvon Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dai-shi

Yeah, I assume most devs open tests/* files from the project root.

Do you want to remove all of cd command part?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All except for cd website as it's required to install node modules.

3. Implement your changes
4. Build the library by running `pnpm run build` _(Pro-tip: `pnpm run build-watch` runs the build in watch mode)_
sukvvon marked this conversation as resolved.
Show resolved Hide resolved
5. Run the tests by running `pnpm run test` and ensure that they pass.
6. You can use `pnpm link` to sym-link this package and test it locally on your own project. Alternatively, you may use CodeSandbox CI's canary releases to test the changes in your own project (requires a PR to be created first)
7. Follow step 4 and onwards from the [General](#General) guide above to bring it to the finish line

##### Documentation

1. Navigate to the [`website`](./website/) folder. (e.g., `cd website`)
2. Install dependencies by running `pnpm install` in the `website` folder
3. Run `pnpm run dev` to start the dev server
4. Navigate to [`http://localhost:9000`](http://localhost:9000) to view the documents
5. Navigate to the [`docs`](./docs/) folder and make necessary changes to the documents. (e.g., `cd docs`)
6. Add your changes to the documents and see them live reloaded in the browser
7. Follow step 4 and onwards from the [General](#General) guide above to bring it to the finish line

Thank you for contributing! :heart:
Loading