BEEQ uses Conventional Commits for all commit messages. This format enables automatic changelog generation and makes the project history easy to navigate.
Commit message validation is enforced by commitlint on every commit, using the @commitlint/config-conventional preset with BEEQ-specific overrides defined in .commitlintrc.ts.
Pull request titles must also follow this format, since PRs are merged using Squash and merge and the PR title becomes the commit message on main.
Format
<type>[optional scope]: <subject>
[optional body]
[optional footer(s)]
Examples
feat(button): add icon-only variant with square aspect ratio
fix(select): prevent tag removal on backspace when input is not empty
docs(storybook): update button usage examples
chore(deps): update @stencil/core to v4.42.0
refactor(datepicker): improve performance with utilities
Commit types
The type field must be one of the following (enforced by commitlint):
| Type | When to use |
|---|
feat | A new feature |
fix | A bug fix |
docs | Documentation-only changes |
style | Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons) |
refactor | A code change that is neither a bug fix nor a new feature |
perf | A change that improves performance |
test | Adding or updating tests |
chore | Changes to the build process, tooling, or auxiliary libraries |
revert | Reverts a previous commit |
ci | Changes to CI configuration or scripts |
build | Changes that affect the build system or external dependencies |
wip | Work in progress (use sparingly; should not land on main) |
release | Release commits (managed by the release tooling) |
Scope
The scope is optional and should be the name of the component or module affected, in lower kebab-case:
feat(bq-button): ...
fix(select): ...
docs(storybook): ...
chore(deps): ...
Subject rules
- Use the present tense and imperative mood: “add feature”, not “added feature” or “adds feature”.
- Do not capitalize the first letter.
- Do not end with a period.
- Keep the entire first line under 72 characters.
- Describe what the commit does, not the issue number it relates to.
Body
The body is optional but encouraged for non-trivial changes. Use it to explain the why behind a change:
- Maximum line length: 500 characters (per line).
- Separate from the subject with a blank line.
- Reference issues and pull requests here (e.g.,
Closes #1234).
Breaking changes
For any commit that introduces a breaking change:
- Append
! after the type (and optional scope).
- Add a
BREAKING CHANGE: footer with a summary and migration instructions.
refactor(checkbox)!: rename `isChecked` property to `checked`
BREAKING CHANGE: the `isChecked` property has been renamed to `checked`.
The `isChecked` property (`is-checked` attribute) is no longer supported
in the checkbox component and has been renamed to `checked`.
Update all usages of `is-checked` to `checked` in your templates.
Deprecations
For commits that deprecate (but do not remove) something, add a DEPRECATED: footer:
feat(tooltip)!: deprecate `trigger` prop in favour of `triggerType`
DEPRECATED: the `trigger` prop is deprecated and will be removed in the
next major release. Use `triggerType` instead.
Documentation-only commits
When a commit changes only documentation and should skip CI, include [ci skip] in the subject:
docs(contributing): update setup instructions [ci skip]
Quick reference card
✅ feat(button): add loading spinner support
✅ fix(dialog): prevent scroll-lock on iOS
✅ refactor(select)!: rename `value` prop to `selectedValue`
✅ chore(deps): update nx to v22.4.2
✅ docs: fix typo in contributing guide [ci skip]
❌ Added loading spinner to button ← past tense, no type
❌ Fix bug. ← ends with period, too vague
❌ feat: Add New Feature ← capitalized subject
❌ WIP stuff ← no type, no conventional format