Skip to content

Latest commit

 

History

History
125 lines (97 loc) · 4.07 KB

CONTRIBUTING.md

File metadata and controls

125 lines (97 loc) · 4.07 KB
Raw

👋 Welcome and thanks for contributing!

🔌 Prerequisites

Tool Version
node =18
yarn >=3

Getting Started

Installation

Update pnp.js, build binaries, and link workspace together.

$ yarn

PnP and Yarn Berry

We use yarn berry (2) with Zero-Installs enabled, so dependencies are committed.

💅 Code style

is fully controlled by our eslint configurations.

📚 History

We prefer to use liner history and because of that you need to know how to work with git rebase.

Hooks

We use 🐶husky to lint your changes and commit messages to save you from common mistakes.

Helpful links about git rebase

Versioning

Semantic Versioning 2.0.0

Summary from semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backward-compatible manner, and
  • PATCH version when you make backward-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Commit messages

Conventional Commits 1.0.0

Summary from conventionalcommits.org:

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer, by describing the features, fixes, and breaking changes made in commit messages.

Message structure:

<type>[optional scope]: <description> [task code if exists]

[optional body]

[optional footer(s)]

Type:

Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests
  • revert: MR/Commit reverts

Description

  • must be written using irregular verbs.
  • must describe what does YOUR CODE, but not what YOU DID

The Best way to understand if your commit message's good is to create sentence like: If applied, will [optional type] <description> [in <scope>].

If applied, will...

  • add jsdoc in card
  • fix typo in property name in theme
  • display columns in reverse order in table

Examples:

feat: add component Card
docs(card): add jsdoc (#7)
fix(theme): typo in property name (#12)
style(table): add semi colon (#2)

Branch naming

The branch name should consist of the squashed commit type and a quick summary.

Examples:

feat/card
fix/interactive-element
docs/readme

Merge Requests

MR is rejected when:

  • pipeline fails (lint/test error).

  • contains unrelated changes.

  • request is behind the default branch.

  • contains merge commits.

  • If MR contains only one commit: title should be the commit message.

  • If MR contains multiple commits: title should the overall summary.

  • If MR contains the issue code: description should contain Closes %{issue_code} automation command, e.g. Closes #7