3.2 KiB
Contributing
Contributors are welcomed!
We try to keep a number of good first issue for new contributors.
If you feel confident, you can also check out the help wanted issues.
To have an idea of the work in the pipeline, feel free to view the js-waku project board.
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 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.
- Chrome (for browser testing).
To ensure interoperability with 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).
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 for commit patches,
- Please test new code, we use mocha, chai, fast-check and karma.
Committing Patches
In general, commits should be atomic 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 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