Skip to content

Latest commit

 

History

History
157 lines (106 loc) · 7.08 KB

CONTRIBUTING.md

File metadata and controls

157 lines (106 loc) · 7.08 KB
Raw

Contributing

Introduction

You are here to help Wave? Awesome! feel welcome and read the following sections in order to know how to ask questions and how to work on something.

Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub

Project setup

  1. Fork and clone the repo
  2. Run npm install to install dependencies
  3. Create a branch for your PR with git checkout -b <ISSUE-NUMBER>/your-branch-name

Check Github official documentation

Tip: Keep your main branch pointing at the original repository and make pull requests from branches on your fork. To do this, run:

git remote add upstream git@github.com:freenowtech/wave.git
git fetch upstream
git branch --set-upstream-to=upstream/main main

This will add the original repository as a "remote" called "upstream," Then fetch the git information from that remote, then set your local main branch to use the upstream main branch whenever you run git pull. Then you can make all of your pull request branches based on this main branch. Whenever you want to update your version of main, do a regular git pull.

Ground Rules

Testing

We test our components with Jest and react-testing-library. You can run the tests locally with npm test (or npm t). To run the tests as you work, run Jest in watch mode with:

npm test -- --watch

Make sure your fixes, improvements and overall code additions is backed with some tests we can use to iterate properly over your contribution in the future

Code style

We use the Prettier to format our code. When you commit your files, they will automatically be adjusted to follow our conventions. To format your work manually, run:

npm run prettier

Commit messages

We are using conventional commits to improve readability commit messages and makes it easier to follow through the project history. The commit message should be structured as follows:

<type>[optional scope]: <description>

[optional body]

[optional footer]

The type describes the intent of the commit (e.g. feat, fix, docs, refactor, revert). In the following you can find an example of a well structured commit message:

fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

You can serve your self with CI tools to make easier the creation of commits with https://github.com/streamich/git-cz

Your First Contribution

Triage tickets

If an unreviewed ticket reports a bug, try and reproduce it. If you can reproduce it, and it seems valid, make a note that you confirmed the bug and accept the ticket. A video or clear steps on how to reproduce a bug is a great way to set up the ground for the next dev.

Write some documentation

Our documentation is great, but it can always be improved. Did you find a typo? Do you think that something should be clarified? Go ahead and suggest a documentation patch!

We use Storybook to run our documentation site at wave.free-now.com.

To add a new component to our documentation site:

  1. Create a new file with the .stories.tsx prefix for your component in /src/stories.
  2. Include a brief description and examples. Props should be configurable via Storybook

To learn more how to add stories go to Storybook docs

Give us your feedback

Feedback, feedback, feedback! We appreciate and need your input to understand your needs, so we can continue delivering great value. If you don't know where to start from, first check with a similar issue is not already created, otherwise create a new one. Also, make sure to share it in our internal channel, so we can discuss effort, impact and priority: #ask-wave.

Take from the backlog

Feel like doing a bit more? You can check what is up for grabs in our public backlog and create a PR for it. All contributions are welcomed!

Distribution channels

We use semantic release to automate our versioning and release process. Currently, we have 3 distribution channels:

  • latest tag (follows the main branch): It is used for releases on the current major (v2)
  • next tag (follows the next branch): It is used for pre-releases on the next major (v3)
  • release-1.34.x tag (follows the 1.34.x branch): It is used to provide maintenance on our previous major version (v1). For more information check semantic-release maintenance releases guide

Tools we use

  1. We use styled-components to style our components.
  2. We use style functions from styled-system whenever possible.

Component patterns

All components should be created with the styled function from [styled-components] and should have the appropriate groups of system props attached.

Default values for props can be set in .attrs() function.

Make sure to always set the default theme prop to our theme! This allows consumers of our components to access our theme values without a ThemeProvider.

Components should always be named exports (as opposed to default exports), because it provides better developer experience and more freedom for potential refactorings. Consider reading this article for more rationale behind this decision.

Adding icons

We use SVGs which are wrapped in react components as icons. These are generated through a script so we don't have to convert them manually. The source SVG files are kept under assets/icons/. If you want to add a new icon add it to that folder and run npm run generate. This will create a new icon component inside the src/icons/ folder.