4.2 KiB
Contributing
Thanks for being willing to contribute!
Table of Contents
How to Contribute
Did you find a bug?
-
Do not open up a GitHub issue if the bug is a security vulnerability in Zap, and instead to refer to our Security Policy.
-
Ensure the bug was not already reported by searching on GitHub under Issues.
-
If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, and as much relevant information as possible.
Did you write a patch that fixes a bug?
-
Open a new GitHub pull request with the patch.
-
Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.
-
Before submitting, please read the Coding Guidelines to know more about our coding conventions and practices.
Do you intend to add a new feature or change an existing one?
- Please join us on slack and check open issues to see what contributions are needed before tackling a task to avoid duplicate work.
Do you have questions about the source code?
- Ask any question about the Zap source code in slack.
Contribution Guidelines
Committing and Pushing changes
We follow the conventional changelog standard for commit messages. You don't have to follow this convention if you don't like to. Just know that when we merge your commit, we'll probably use "Squash and Merge" so we can change the commit message :)
Valid conventional commit types are:
build
: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)chore
: Other changes that don't modify src or test filesci
: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)docs
: Documentation only changesfeat
: A new featurefix
: A bug fixperf
: A code change that improves performancerefactor
: A code change that neither fixes a bug nor adds a featurerevert
: Reverts a previous commitstyle
: 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
Example
git commit -m "feat(close-channel): wire up close channel to UI"
Please make sure to run the tests before you commit your changes. You can run npm test
which will run the test suite.
Git hooks
There are git hooks set up with this project that are automatically installed when you install dependencies. They're really handy, with them in place you will get:
- Automatic reformatting of changed files on commit via prettier
- Automatic lint of changed files on commit (will not allow commit with files that fail lint) via eslint
- Automatic validation of commit message format (will not allow commit with invalid commit message) via commitlint
Branch Names
Branch names should start with a valid conventional commit type followed by /description_of_branch
.
Example
git branch feat/close-channel-ui
Pull Requests
The master
branch will be used for all pull requests for the time being. This may change as the repo and contributors grow.
Style Guide
This project has eslint rules and pull requests should pass npm run lint
before being merged. The eslint rules are not final by any means and can be changed if necessary.
Tests
Tests should try to be written for every feature/fix and pass npm run test
before being merged. With the demand for the Lightning Network and Zap rising, rapid development will naturally leave some code untested but we should all try our best.