github-starred/conventionalcommits.org
2
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2026-03-22 12:44:37 -05:00
Code Issues 153 Packages Projects Releases Wiki Activity

Stale Angular reference: linked document doesn't define chore #232

New Issue
Open
opened 2026-02-17 11:55:02 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-02-17 11:55:02 -06:00
Owner
Copy Link

Originally created by @nurse-the-code on GitHub (Jan 13, 2026).

Stale Angular reference: linked document doesn't define chore

Problem

The specification recommends commit types including chore:

"Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning... Additional types are allowed, for example, @commitlint/config-conventional (based on the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others."

The spec links to Angular's CONTRIBUTING.md at a specific commit:
https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines

However, this document does not define chore. It only lists: build, ci, docs, feat, fix, perf, refactor, style, and test.

The chore type actually comes from the older AngularJS project:
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md

Where it's defined as: "Changes to the build process or auxiliary tools and libraries such as documentation generation"

Impact

Users following the spec who want to use chore (a commonly recommended type) cannot find its definition in the linked reference. This creates confusion about what chore means and when to use it.

Suggested Solutions

Define the types directly in the spec (see #634 for a related proposal), removing the dependency on external documentation that may change or become stale

Related Issues

  • #634 - Proposal: Clearer definitions for Conventional Commit types (addresses the broader problem of type definitions living outside the spec)

Additional Context

The Angular project appears to have intentionally removed chore in favor of build for build-related changes. This divergence between the spec's recommendation and the linked reference suggests the external dependency model for type definitions is fragile.

Originally created by @nurse-the-code on GitHub (Jan 13, 2026). ## Stale Angular reference: linked document doesn't define `chore` ### Problem The specification recommends commit types including `chore`: > "Additional types are not mandated by the Conventional Commits specification, and have no implicit effect in Semantic Versioning... Additional types are allowed, for example, @commitlint/config-conventional (based on the Angular convention) recommends `build:`, `chore:`, `ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others." The spec links to Angular's CONTRIBUTING.md at a specific commit: https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines **However, this document does not define `chore`.** It only lists: `build`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `style`, and `test`. The `chore` type actually comes from the older **AngularJS** project: https://github.com/angular/angular.js/blob/master/DEVELOPERS.md Where it's defined as: *"Changes to the build process or auxiliary tools and libraries such as documentation generation"* ### Impact Users following the spec who want to use `chore` (a commonly recommended type) cannot find its definition in the linked reference. This creates confusion about what `chore` means and when to use it. ### Suggested Solutions **Define the types directly in the spec** (see #634 for a related proposal), removing the dependency on external documentation that may change or become stale ### Related Issues - #634 - Proposal: Clearer definitions for Conventional Commit types (addresses the broader problem of type definitions living outside the spec) ### Additional Context The Angular project appears to have intentionally removed `chore` in favor of `build` for build-related changes. This divergence between the spec's recommendation and the linked reference suggests the external dependency model for type definitions is fragile.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
discussion
enhancement
greenkeeper
help wanted
meeting-agenda
operations
process
pull-request
Mirrored from GitHub Pull Request
 question
suggestion
support
triaged
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#232
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?