Home Manual Reference Source

How Can I Contribute?

The following is a set of guidelines for contributing to Reach.

Report Bugs

This section guides you through submitting a bug report for Reach. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

Before creating bug reports, please check this list as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible. If you'd like, you can use this template to structure the information.

Before Submitting A Bug Report

How Do I Submit A (Good) Bug Report?

Bugs are tracked as GitHub issues. Create an issue on the repository and provide the following information.

Explain the problem and include additional details to help maintainers reproduce the problem:

Provide more context by answering these questions:

Include details about your configuration and environment:

Template For Submitting Bug Reports

[Short description of problem here]

**Reproduction Steps:**

1. [First Step]
2. [Second Step]
3. [Other Steps...]

**Expected behavior:**

[Describe expected behavior here]

**Observed behavior:**

[Describe observed behavior here]

**Screenshots and GIFs**

![Screenshots and GIFs which follow reproduction steps to demonstrate the problem](url)

**Reach version:** [Enter Reach version here]
**Browser and version:** [Enter Browser name and version here]
**OS and version:** [Enter OS name and version here]

**Additional information:**

* Problem started happening recently, didn't happen in an older version of Reach: [Yes/No]
* Problem can be reliably reproduced, doesn't happen randomly: [Yes/No]

Develop new features / Fix bugs

Prepare your development environment

Start with the obvious and either clone or fork this repo. Run npm install. We advise you to use a recent version of node (5+).

You can use your favorite IDE. Try to enable eslint with the project configuration file .eslintrc.yml within your IDE, it will greatly speed things up when you get to the commit phase.

All files should be UTF-8 encoded and using LF (not CRLF, yes it's for you Windows users).

Document your code

Reach rely on esdoc for es6 code documentation. Several npm task exists to generate/serve the doc with hot reload enabled. Use npm run serve to keep an eye on your doc while you code.

Test your code

Reach uses Karma & Jasmine to test the code.

To be able to run the test, you will need to create a .account.json file with your Webcom account credentials at the root of the project.

    "WEBCOM_EMAIL": "<Your webcom account's email>",
    "WEBCOM_PASSWORD": "<Your webcom account's password>"

Alternatively, these values can be set as environment variables.

Karma is configured to use your local Chrome & Firefox to run the tests so you have to install at recent version of both Chrome/Chromium & Firefox.

Run the tests while you code with npm start. If you want to check your coverage, run npm run test:coverage, the report will be in the coverage folder.

Be advised that the test MUST pass in order to push your modifications.

Commit your modifications


Even though built files in the dist folder are not in the .gitignore file, they MUST not be committed manually. Reach uses travis-ci to generate & publish the library. The version number is computed by semantic-release based on the commit messages.


Reach uses semantic-release along with commitizen and validate-commit-msg to simplify the commit message format convention.

You will need to install commitizen globally first and then use git cz to commit instead of the traditional git commit -m ....