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>

Where:

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

Types

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

TypeDescription
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

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

ScopeDescription
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.

Example

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.