Skip to content

Latest commit

 

History

History
98 lines (68 loc) · 3.49 KB

CONTRIBUTING.md

File metadata and controls

98 lines (68 loc) · 3.49 KB
Raw

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue before making a change.

Please note we have a code of conduct, please follow it in all your interactions with the project.

Pull Request Process

  1. Ensure any install or build dependencies are removed before the end of the layer when doing a build.
  2. Update the README.md with details of changes to the interface, this includes new methods/options, changes to existing methods/options.
  3. Do not modify the CHANGELOG.md or the version number in package.json our CI/CD will automatically update this.
  4. All pull request require a passing review by at least one other developer prior to being merged.
  5. All pull request require passing test with 100% code coverage and passing linting

Coding Rules

To ensure consistency throughout the source code, keep these rules in mind as you are working:

  • All features or bug fixes must be tested by one or more specs (unit-tests).

  • All public API methods must be documented.

  • We use tslint to lint all code in this project.

    Please use Prettier for formatting.

Commit Message Format

This specification is inspired and supersedes the [AngularJS commit message format][commit-message-format].

We have very precise rules over how our Git commit messages must be formatted. This format leads to easier to read commit history.

Each commit message consists of a header, a body, and a footer.

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and must conform to the Commit Message Header format.

The body is mandatory for all commits. When the body is required it must be at least 20 characters long.

The footer is optional.

Any line of the commit message cannot be longer than 100 characters.

Commit Message Header

<type>: <short summary>
  │            │
  │            └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │
  │
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|style|test

The <type> and <summary> fields are mandatory.

Type

Must be one of the following:

  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code
  • 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
  • test: Adding missing tests or correcting existing tests
  • chore: Changes to the build process or auxiliary tools and libraries

Commit Message Body

Just as in the summary, use the imperative, present tense: "fix" not "fixed" nor "fixes".

Explain the motivation for the change in the commit message body. This commit message should explain why you are making the change. You can include a comparison of the previous behavior with the new behavior in order to illustrate the impact of the change.

Revert commits

If the commit reverts a previous commit, it should begin with revert:, followed by the header of the reverted commit.

The content of the commit message body should contain:

  • information about the SHA of the commit being reverted in the following format: This reverts commit <SHA>,
  • a clear description of the reason for reverting the commit message.