Any contribution, big or small, is welcome! If it's a feature, we'd recommend creating an issue for it first so that the implementation can be decided on before the PR goes up and to make sure no one is working on the same feature. It makes the review process a bit smoother, so you don't have to keep going back adding things. If it's just a bug fix though, feel free to just put up the PR directly!
Some guidelines you should follow when submitting a PR:
- We use
generate-changelogfor automatic changelog generation whenever we deploy, so please follow the commit message format:feat(info): add animations when toggling. - Ideally, your PR has one commit in it. If you you need to add another one because of a typo or refactor, you should squash your commits together. This makes the changelog and commit history much more managable to go through. If you need help squashing them, we can always help you out!
- Any code should have associated tests with it. Though this isn't a mission-critical API, it would be nice if it didn't go down every week. Having a well-tested API helps mitigate bugs and downtime. We use Coveralls to enforce 100% code coverage, so the build will fail if that threshold is not met.
- Before submitting the PR, you should make sure that your code passes the linter. Running
npm run lintlocally will speed things up because the TravisCI build will fail if the linting doesn't pass.