mirror of https://github.com/waku-org/js-waku.git
72 lines
3.2 KiB
Markdown
72 lines
3.2 KiB
Markdown
# Contributing
|
|
|
|
Contributors are welcomed!
|
|
|
|
We try to keep a number of [`good first issue`](https://github.com/status-im/js-waku/labels/good%20first%20issue) for new contributors.
|
|
If you feel confident, you can also check out the [`help wanted`](https://github.com/status-im/js-waku/labels/help%20wanted) issues.
|
|
|
|
To have an idea of the work in the pipeline, feel free to view the [js-waku project board](https://github.com/status-im/js-waku/projects/1).
|
|
This project board is to prioritize the work of core contributors so do not be deterred by issues in the `Icebox` or bottom of the `Backlog`.
|
|
|
|
Do note that we have a [CI](./.github/workflows/ci.yml) powered by GitHub Action.
|
|
To help ensure your PR passes, just run before committing:
|
|
|
|
- `npm run fix`: To format your code,
|
|
- `npm run check`: To check your code for linting errors,
|
|
- `npm run test`: To run all tests
|
|
|
|
## Build & Test
|
|
|
|
To build and test this repository, you need:
|
|
|
|
- [Node.js & npm](https://nodejs.org/en/).
|
|
- Chrome (for browser testing).
|
|
|
|
To ensure interoperability with [nim-waku](https://github.com/status-im/nim-waku/), some tests are run against a nim-waku node.
|
|
This is why the relevant docker images for the node is pulled as part of the `pretest` script that runs before `npm run test`.
|
|
|
|
If you do not want to run `npm run test`, you can still pull the relevant nim-waku docker image by running `npm run pretest`.
|
|
|
|
Note that we run tests in both NodeJS and browser environments (using [karma](https://karma-runner.github.io/)).
|
|
Files named `*.node.spec.ts` are only run in NodeJS environment;
|
|
Files named `*.spec.ts` are run in both NodeJS and browser environment.
|
|
|
|
## Guidelines
|
|
|
|
- Please follow [Chris Beam's commit message guide](https://chris.beams.io/posts/git-commit/) for commit patches,
|
|
- Please test new code, we use [mocha](https://mochajs.org/),
|
|
[chai](https://www.chaijs.com/),
|
|
[fast-check](https://github.com/dubzzz/fast-check)
|
|
and [karma](https://karma-runner.github.io/).
|
|
|
|
### Committing Patches
|
|
|
|
In general, [commits should be atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention)
|
|
and diffs should be easy to read.
|
|
For this reason, do not mix any formatting fixes or code moves with actual code changes.
|
|
|
|
Commit messages should be verbose by default consisting of a short subject line (50 chars max),
|
|
a blank line and detailed explanatory text as separate paragraph(s),
|
|
unless the title alone is self-explanatory in which case a single title line is sufficient.
|
|
|
|
Commit messages should be helpful to people reading your code in the future, so explain the reasoning for
|
|
your decisions.
|
|
|
|
If a particular commit references another issue, please add the reference.
|
|
For example: `refs #1234` or `fixes #4321`.
|
|
Using the `fixes` or `closes` keywords will cause the corresponding issue to be closed when the pull request is merged.
|
|
|
|
Commit messages should never contain any `@` mentions (usernames prefixed with "@").
|
|
|
|
Please refer to the [Git manual](https://git-scm.com/doc) for more information
|
|
about Git.
|
|
|
|
### Releasing
|
|
|
|
`js-waku` has two types of releases:
|
|
- public releases;
|
|
- pre releases;
|
|
|
|
Public releases happen by merging PRs opened by `release-please` action.
|
|
Pre releases happen manually by triggering [this workflow](https://github.com/waku-org/js-waku/actions/workflows/pre-release.yml)
|