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

Latest commit

 

History

History
66 lines (40 loc) · 3.06 KB

CONTRIBUTING.md

File metadata and controls

66 lines (40 loc) · 3.06 KB
Raw

Contributing

The following guidelines must be followed by all contributors to this repository. Please review them carefully and do not hesitate to ask for help.

Code of Conduct

  • Review and test your code before submitting a pull request.
  • Be kind and professional. Avoid assumptions; oversights happen.
  • Be clear and concise when documenting code; focus on value.
  • Don't commit commented code to the main repo (stash locally, if needed).

See our code of conduct for more details.

Running Locally

Please see the README for details.

Running Tests

We use Jest as the test runner for all our tests and ESLint for linting. Prior to opening a pull request make sure to run npm test.

To run the unit tests and linting:

$ npm test

If you would like to run only the unit tests:

npm run test:unit

Or only linting:

npm run test:lint

To auto fix eslint rule failures that are autofixable run npm run test:lint -- --fix

Opening the PR

Pull Request Guidelines

  • Keep PRs small, there should be one change per pull request.

  • All pull requests must have descriptions and a link to corresponding issue(s) if applicable.

  • Keep commit history clean. Follow commit message guidelines (see below) and squash commits as needed to keep a clean history. Remember that your git commit history should tell a story that should be easy to follow for anyone in the future.

  • Before making substantial changes or changes to core functionality and/or architecture open up an issue to propose and discuss the changes.

  • Be patient. The review process will be thorough. It must be kept in mind that changes to our repos are platform wide and thus are not taken lightly. Be prepared to defend every single line of code in your pull request. Attempting to rush changes in will not work.

  • Write tests for your changes. A feature is not considered done until it has tests and/or a test plan. It does not matter if code coverage shows 100%, tests are expected for all changes.

Getting in Contact

Git Commit Guidelines

We follow precise rules for git commit message formatting. These rules make it easier to review commit logs and improve contextual understanding of code changes. This also allows us to auto-generate the CHANGELOG from commit messages and automatically version Fetch Enhancers during releases.

For more information on the commit message guidelines we follow see conventional commits.