Skip to content
This repository has been archived by the owner on Jan 3, 2024. It is now read-only.

Latest commit

 

History

History
102 lines (69 loc) · 4.52 KB

CONTRIBUTING.md

File metadata and controls

102 lines (69 loc) · 4.52 KB
Raw

Contributing Guide

Getting started

Prerequisites

  • You have Node installed at v10.0.0+ and Yarn at v1.2.0+.
  • You are familiar with Git

Branch organisation

According to our release schedule, we organize our branches into:

  • master: is the project permanent branch which should always reflects a production-ready state
  • feat: If it’s a feature pull request. In this workflow, a new contributor starts from the master branch.
  • fix: If you need to send a bug fix pull request
  • chore: If is a small change (update something without impacting the user).

Branch naming scheme

  • feat/foo-bar for new features
  • fix/foo-bar for bug fixes
  • chore/foo-bar for anything else. Use chore(docs/style/...) to scope your task.

Conventional commits

We have very precise rules on how git commit messages should be formatted. More readable messages makes the project history easier to search.

Commit message format

Each commit message must have a header that includes the type, the scope (optional), and the description:

<type>[optional scope]: <description>

Example:

fix(storybook): Allow fonts to be rendered in storybook.

Read more about Conventional Commits and allowed types on conventionalcommits.org.

Found a bug?

Use Github Issues for bug tracing.

Before reporting a new bug, ensure that the bug was not already reported and is not fixed.

If you find a bug in the source code, you can help us by submitting an issue to our Git Repository. Even better, you can submit a Pull Request with a fix.

Proposing changes

  1. To do a “substantial” change - change to the API or introducing a new feature - we highly recommend using our RFC process.
  2. To report a bug, we recommend using our bug issue tracker and provide a reproduction of the bug.

Requests for comments

Many changes, including bug fixes and documentation improvements can be implemented and reviewed via the normal GitHub pull request workflow.

Some changes, though, are “substantial” and should be put through a bit of a design process in order to produce a consensus among the core team.

The “RFC” (Request For Comments) process is intended to provide a consistent and controlled path for new features to enter a project. You can create a new RFC document by using the Feature template in the project issues area.

Sending pull requests

Before submitting a pull request, please make sure you:

  1. Clone the repository and create your branch from master.
  2. Create a new feature branch.
  3. Run yarn install in the project root to install project dependencies.
  4. Do the necessary developments.
  5. Add tests if you’ve fixed a bug or added code that needs to be tested and ensure the test suite passes (yarn test).
  6. Make sure your code lints (yarn lint).
  7. Update the project README with details of the changes made to the interface.
  8. Rebase your work on top of the base branch.
  9. Open a Pull Request to master.
  10. Code owners should automatically be requested for review your code.
  11. Once reviewed and approved, one of the project master/owners will do the merge and the respective release.

Development workflow

After cloning the project, run yarn install to fetch its dependencies. Then, you can run several commands:

  • yarn gr runs locally built version of Garment. Allows to test changes during the development
  • yarn watch runs TypeScript compiler in a watch mode which incrementally rebuilds changed files
  • yarn build builds Garment using TypeScript compiler
  • yarn release updates the versions of changed Garment's packages and publishes them