Contributing to the React Library

Linting

This project uses Prettier and Stylelint for linting.

PRs

In order to be accepted, a PR:

• MUST be created from the development branch
• MUST pass the CI Build (test locally with npm test)
• MUST include a CHANGELOG description of the relevant changes
• MUST link to any relevant issue(s), typically to a JIRA ticket
• MUST match requirements specified in the design documentation for the component
• MUST add the component to the index.ts export

Additionally, a PR:

• SHOULD pass code requirements (compile)
• SHOULD follow the naming conventions and patterns set up in in the library
• SHOULD have all prop types declared. (Not familiar with Typescript and prop types? Check out this cheatsheet.)
• SHOULD have stories that show the full functionality of the component in different states (e.g., minimum amount of props, maximum amount of props, different visual states)
• SHOULD have unit tests and snapshot tests that cover any added functionality or design
• SHOULD contain components that are responsive, accessible, and mobile-first
• SHOULD contain functional components (i.e., stateless) if possible for the component. Not sure what that means? Check out Twilio's guide to functional components.
• SHOULD include stories with controls to show off the use of the component – See Storybook's guide to controls here.
• SHOULD NOT break the test suite in any other way (npm run test)

Who approves pull requests?

All code reviews MUST be approved by at least 1 maintainer. As a contributor, please stay on top of re-requesting reviews from your reviewers!

Maintainers:

• Marty Brutvan (bigfishdesign13)
• Edwin Guzman (edwinguzman)

Contributors:

• Olivia Wong (oliviawongnyc)
• Emma Mansell (7emansell)
• Jackie Quach (jackiequach)
• Isabelle Stettler (isastettler)

What do I do after my PR was approved?

Congrats on your approval! To move forward, your code MUST now be merged into the development branch.

Once your PR has been merged, you may be asked by a maintainer to run a release. Those instructions can be found here.

Storybook

Running the static Storybook instance locally is OPTIONAL and should not be necessary. When changes are merged into development, Travis CI will automatically build the Storybook instance as a static site and deploy to the gh-pages branch. This branch is used to deploy to Github Pages.

If you need to test the static build locally, run npm run build-storybook:v3 and then view the reservoir/v3/index.html file in a browser. No server needs to be running since this is a static website. If you do run the static Storybook npm script, do not commit the storybook-static directory.

Need help?

Are you stuck or unsure how to make some of these things work? Publish a draft PR and we can provide pointers. Would you like extra clarification with some of these concepts? The Design System slack channel has a bunch of people who want to help.