Skip to content

Latest commit

 

History

History
74 lines (48 loc) · 4.41 KB

CONTRIBUTING.md

File metadata and controls

74 lines (48 loc) · 4.41 KB

Contributing

Contributions are welcome and will be fully credited.

We accept contributions via Pull Requests on Github.

Quick Links

Development Setup

You will need Node.js version 8+ and Yarn.

After cloning the repo, run:

$ yarn

Then, you can run several commands:

  • yarn build creates a dist folder with the production ready sources
  • yarn dev is like yarn build but watches for file changes and rebuilds the sources on file change
  • yarn lint checks code style and reformats the code
  • yarn test runs the unit tests in interactive mode
  • yarn ci like yarn test but configured to run in a CI environment

It's recommended to run yarn test to make sure you don’t introduce any regressions as you work on your change. However it can be handy to try your build of the Color Wheel in one of the components it supports.

Style Guide

We use an automatic code formatter called Prettier. Run yarn lint after making any changes to the code.

However, there are still some styles that the linter cannot pick up. If you are unsure about something, looking at Airbnb’s Style Guide will guide you in the right direction.

Commit messages should follow the commit message convention so that's easier to generate changelogs.

Project Structure

  • /src contains the source code. The codebase is written in ES2015 and the entry point is /src/main.js
  • /dist contains built files for distribution. Not tracked in the git repository, but will be created every time yarn build or yarn dev is run.
  • /__tests__ contains all tests. The unit tests are written and run with Jest
  • /.circleci contains configuration for CircleCI which builds and runs the tests in a CI environment

Issues & Pull Requests Guidelines

Issues

GitHub Issues for public bugs. Before filing a new task, try to make sure your problem doesn’t already exist. The best way to get your bug fixed is to provide a reduced test case. A JSBin, Codepen, JSFiddle or Codesandbox is a great starting point.

Pull Requests

Working on your first Pull Request? You can learn how from this free video series:

How to Contribute to an Open Source Project on GitHub

To help you get your feet wet and get you familiar with our contribution process, look for GitHub issues with the label "good first issue" which contain bugs that have a relatively limited scope. This is a great place to get started.

If you decide to fix an issue, please be sure to check the comment thread in case somebody is already working on a fix. If nobody is working on it at the moment, please leave a comment stating that you intend to work on it so other people don’t accidentally duplicate your effort.

If somebody claims an issue but doesn’t follow up for more than two weeks, it’s fine to take it over but you should still leave a comment.

  • The master branch is basically just a snapshot of the latest stable release. All development should be done in dedicated branches. Do not submit PRs against the master branch.
  • Document any change in behavior - Make sure the README.md and any other relevant documentation are kept up-to-date.
  • Checkout a topic branch from the relevant branch, e.g. master, and merge back against that branch.
  • Send coherent history - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please squash them before submitting.
  • Make sure npm test passes. (see Development Setup)
  • One pull request per feature - If you want to do more than one thing, send multiple pull requests.
  • If adding new feature add accompanying test case and a reason to add this feature. Ideally you should open a suggestion issue first and have it greenlighted before working on it.
  • When fixing a bug provide a description of the bug in the PR, live demo preferred. Don't forget to add appropriate tests if applicable

Happy coding!