Your contributions to this project are very welcome, be it a new feature, a bugfix, better documentation, or something else. Feel free to create a pull request, but please adhere to the format specified below. This strict format is required so semantic-release can automatically handle semantic versioning and update changelogs. An automated check ensures that pull requests have a matching title:
If this check fails, simply edit the title of the pull request. There is no need to close it and to create a new one.
The title must follow the Conventional Commits convention. It must consist of (in this order)
- a type (see below),
- an optional scope in parentheses (see below),
- an exclamation mark if and only if it is a breaking change,
- a colon and a summary of the purpose of the pull request.
All types from Commitizen are allowed. Pick the one that fits best:
| Type | Meaning |
|---|---|
feat |
New feature |
fix |
Bug fix |
docs |
Documentation only changes |
test |
Adding missing tests or correcting existing tests |
perf |
Changes that improve performance |
refactor |
Changes that neither fix a bug nor add a feature |
style |
Changes to code style (whitespace, formatting, missing semicolons, etc) |
build |
Changes that affect the build system or external dependencies (e.g. npm) |
ci |
Changes to CI configuration files and scripts (e.g. GitHub Actions) |
revert |
Reverting a previous commit |
chore |
Other changes that don't modify src or test files |
If you want to specify exactly which part of the code is affected by your pull request, you can add a scope in parentheses after the type. No specific rule applies for the choice of the scope, just skim the commit history to see if a fitting scope has been used before.
feat(listView): sort entries alphabeticallydocs: write contributing guiderefactor!: drop support for older browsers(the exclamation mark denotes a breaking change)
Use the provided template. It should be suggested automatically.