feat(cz)!: align validation and errors to Conventional Commits spec#76
Merged
feat(cz)!: align validation and errors to Conventional Commits spec#76
Conversation
… spec - Accept BREAKING-CHANGE as synonym for BREAKING CHANGE (spec #16) - BREAKING CHANGE must be uppercase — lowercase is rejected (spec #15) - Error messages now quote spec language: - "commits MUST be prefixed with a type" (spec #1) - "description MUST immediately follow the colon and space" (spec #5) - "breaking changes MUST be indicated by a BREAKING CHANGE footer" (spec #13) - Move _err/_hint helpers to shared helpers.sh - All error output uses _err/_hint consistently across commands BREAKING CHANGE: error message strings changed — tooling that parses stderr output (e.g. CI scripts matching specific error text) may need updating
Contributor
📊 Coverage Report
|
- cmd_create uses "description MUST NOT be empty" (practical for interactive) - Strict BREAKING CHANGE regex: space or hyphen only (no tab/newline) - config.sh warning converted to _hint helper - Added test for BREAKING-CHANGE with explicit --breaking-footer flag
Centralize all error messages in an associative array registry (error_codes.sh) with commitlint-style codes like [type-enum], [scope-required], [body-leading-blank]. All _err calls now use code lookups with printf formatting, making errors parseable.
Remove redundant message text checks from stderr assertions, keeping only the [error-code] bracket checks. Value-specific checks (filenames, scope names) are preserved.
The Conventional Commits spec requires: "body MUST begin one blank line after the description." Single-line messages (no body) are unaffected. Closes #75.
6 tasks
vabatta
changed the title
vabatta
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Aligns
czvalidation rules, error messages, and output to the Conventional Commits v1.0.0 spec. Adds machine-readable error codes and the-bshort flag.Changes
New enforcement:
BREAKING-CHANGEaccepted as synonym forBREAKING CHANGEin footersBREAKING CHANGEmust be uppercase (lowercasebreaking change:rejected)Error codes:
error_codes.sh) with kebab-case codes like[type-enum],[scope-required],[body-leading-blank]_errcalls use code lookups with printf formatting for machine-readable output[error-code]only, not message textCLI:
-bshort flag for--{no-}breaking-footerRefactor:
_err/_hinthelpers to sharedhelpers.shlint,create,hook,init,config) use_err/_hintconsistentlyDocs:
gitcommitizen(5)mapping spec rules to enforcement-bshort flag in manpage, completionsBreaking Change
Error message strings changed. CI scripts or tooling that parse
cz lintstderr for specific text should use the[error-code]brackets instead.Test plan
BREAKING-CHANGEsynonym tests[error-code]assertions