🎉🏅 Thanks for helping us improve this project! 🙏
This document outlines some of the practices we care about. If you have any questions or suggestions about the process, feel free to open an issue .
If you find any mistakes in the docs or a bug in the code, please open an issue in Github so we can look into it. You can also create a PR fixing it yourself, or course.
If you report a bug, please follow these guidelines:
- Make sure the bug exists in the latest version.
- Include instructions on how to reproduce the issue.
The instructions should be as minimal as possible
and answer the three big questions:
- What are the exact steps you took? This includes the exact versions of node, npm, and any packages involved.
- What result are you expecting?
- What is the actual result?
For small documentation changes, you can use Github's editing feature. The only thing to keep in mind is to prefix the commit message with "docs: ". The detault commit message generated by Github will lead to a failing CI build.
For larger updates to the documentation it might be better to follow the instructions for contributing code below.
Note: If you're planning on making substantial changes, please open an issue first to discuss your idea. Otherwise you might end up investing a lot of work only to discover that it conflicts with plans the maintainers might have.
The general steps for creating a pull request are:
- Create a branch for your change.
Always start your branch from the latest
master
. We often prefix the branch name with our initials, e.g.jk-a-change
. - Run
npm install
to install the dependencies. - If you're fixing a bug, be sure to write a test first. That way you can validate that the test actually catches the bug and doesn't pass.
- Make your changes to the code. Remember to update the tests if you add new features or change behavior.
- Run the tests via
npm test
. This will also run style checks and other validations. You might see errors about uncommitted files. This is expected until you commit your changes. - Once you're done,
git add .
andgit commit
. Please follow the commit message conventions described below. - Push your branch to Github & create a PR.
In addition to any linting rules the project might include, a few general rules of thumb:
- Try to match the style of the rest of the code.
- We prefer simple code that is easy to understand over terse, expressive code.
- We try to structure projects by semantics instead of role.
E.g. we'd rather have a
tree.js
module that contains tree traversal-related helpers than ahelpers.js
module. - Actually, if you create helpers you might want to put those into a separate package. That way it's easier to reuse them.
(Notes for internal team)
This multi-repository is managed with lerna 2.x.
When a PR has been merged to master, we can publish new package(s), maintain tags, bump versions etc. by running:
$ ./node_modules/.bin/lerna publish