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 test: To run all tests, including lint checks.
Build & Test
To build and test this repository, you need:
- Node.js & npm.
- Chrome (for browser testing).
- g++ & make (to build nim-waku)
To ensure interoperability with nim-waku, some tests are run against a nim-waku node.
This is why nim-waku is present as a git submodule, which itself contain several submodules.
At this stage, it is not possible to exclude nim-waku tests, hence git submodule update --init --recursive is run before testing (see pretest script).
If you do not want to run npm run test, you can still build nim-waku 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.