- First search the open issues to see if someone has already created a similar issue
- If you find an existing issue, sit tight. Please do not comment just to say "+1" or "me too".
- If your issue is unique, file a new issue here.
BEFORE YOU START: Please create an issue that documents your change before you submit a PR.
- Fork the repository
- Install dependencies by running
npm install
- Run
npm run verify && npm run build
to ensure the package builds successfully without any changes - Write the code for your feature/fix
- Write tests for the change - ensuring that every code branch is effectively tested
- Update the documentation as necessary
- Run
npm run verify && npm run build
before committing to ensure the code passes all tests/linters/etc - Commit your changes following the Commit message conventions below
- Submit a PR for review
We are following the Conventional Commits format as popularized by the Angular commit format. This is enforced by commitlint and used to automatically publish new versions with semantic-release.
At a minimum, every commit message should include following:
<type>: <short summary>
You can optionally include a body or footer if there's additional information that's important to add to the commit message:
<type>: <short summary>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Must be one of the following:
fix
: Bug fix (PATCH version)perf
: Performance improvement (PATCH version)feat
: New feature (MINOR version)refactor
: Changes source code without affecting functionality in any way (no new version)docs
: Update documentation only (no new version)test
: Add/update/fix test (no new version)
A brief description of the change. Use the imperative, present tense: "fix" not "fixed" nor "fixes".
Additional information to expand on the short summary
If the change is a breaking change, be sure to start this section with BREAKING CHANGE: <breaking change summary>
and go on to summarize the migration instructions.