PR Title Conventions

Well-structured commit messages provide a clear project history and make it easier for maintainers and contributors to understand the changes. We use the conventional commits format to ensure consistency across all commits. Here's how you can structure your commit messages:

Commit Message Structure#

A commit message using the conventional commit format looks like this:

<type>(<scope>): <subject>


  • <type> classifies the kind of change being made.
  • <scope> (optional) describes where the change was made.
  • <subject> is a brief description of the change.


Here are the types you can use to classify your changes:

featA new feature.
fixA bug fix.
refactorA code change that neither fixes a bug nor adds a feature.
docsDocumentation-only changes.
testAdding or updating tests.
choreRoutine tasks like updating dependencies or other non-code changes.
ciChanges related to Continuous Integration.


Scopes help in pinpointing where exactly in the codebase the change happened:

No scopeGeneral changes to the core widgetbook package.
cliChanges specific to the widgetbook_cli package.
annotationModifications in the widgetbook_annotation package.
generatorUpdates concerning the widgetbook_generator package.
releaseCommits related to version releases.


Following the convention, a commit that adds a new command to the CLI package would be:

  _Example:_ `feat(cli): add new CLI command`

By adhering to these conventions, you make the project's history more readable and accessible, making it easier for maintainers and contributors to navigate through changes.