Skip to content

Latest commit

 

History

History
128 lines (86 loc) · 4.04 KB

CONTRIBUTING.md

File metadata and controls

128 lines (86 loc) · 4.04 KB
Raw

Contributing

Contributions are always welcome, no matter how large or small!

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

Please follow the code of conduct in all your interactions with the project.

Developer Startup Guide

This section will walk you through how to get started working with the code.

Environment

Verify that node.js is installed.

Verify that pnpm is installed.

Alternatively, we recommend you install Volta to run the correct node.js and package manager versions for this project.

All code changes must work on the minimum Node version specified in package.json under the engines key.

Setup

Fork the papr repository to your GitHub Account.

Then, run:

$ git clone https://github.com/<your-github-username>/papr
$ cd papr
$ pnpm install

Running tests

Unit tests:

$ pnpm test

TypeScript tests:

$ pnpm test:types

Linting tests:

$ pnpm lint

Running tests in watch mode:

$ pnpm watch
$ pnpm watch:types

Commit messages

This repository follows the Conventional Commits standard.

The format should look something like the following (note the blank lines):

<type>[optional scope]: <description>

[optional body]

[optional footer]

The types allowed are the types enforced by the @commitlint/config-conventional package:

  • build
  • chore
  • ci
  • docs
  • feat
  • fix
  • perf
  • refactor
  • revert
  • style
  • test

This helps us automate the HISTORY.md generation.

This repository follows semver versioning. The metadata from the commit messages is used when determining the next version to be released:

  • major versions: feat commits with BREAKING CHANGE labels inside the commit footer
  • minor versions: feat commits
  • patch versions: all non-feat commits

Pull Request Process

  1. Create your branch from main
  2. Make your code or other changes.
  3. Add or update relevant unit/type tests.
  4. Push the code to your forked repository and open a draft pull request (please follow the guidelines in How to write the perfect pull request)
  5. Perform a self-review using the reviewer guidelines below prior to taking the PR out of draft state.

Reviewer Guidelines

Reviewers should use the following questions to evaluate the implementation for correctness/completeness and ensure all housekeeping items have been addressed prior to merging the code.

  • Correctness/completeness

    1. Do you fully understand the implementation? (Would you be comfortable explaining how this code works to someone else?)
    2. Is the intention of the code captured in relevant tests?
      • Does the description of each test accurately represent the assertions?
      • For any test explicitly called out on the issue as desirable to implement, was it implemented?
    3. Could these changes impact any adjacent functionality?
    4. Are there any errors that might not be correctly caught or propagated?
    5. Is there anything that could impact performance?
    6. Can you think of a better way to implement any of the functional code or tests? "Better" means any combination of:
      • more performant
      • better organized / easier to understand / clearer separation of concerns
      • easier to maintain (easier to change, harder to accidentally break)

  • Housekeeping

    1. Does the title and description of the PR reference the correct issue and does it use the correct conventional commit type (e.g., fix, feat, test, breaking change etc)?
    2. If there are new TODOs, has a related issue been created?
    3. Should any documentation be updated?