René's URL Explorer Experiment

Title: fix(cz_customize): set commit_parser default that captures change_type by bearomorphism · Pull Request #1970 · commitizen-tools/commitizen · GitHub

Open Graph Title: fix(cz_customize): set commit_parser default that captures change_type by bearomorphism · Pull Request #1970 · commitizen-tools/commitizen

X Title: fix(cz_customize): set commit_parser default that captures change_type by bearomorphism · Pull Request #1970 · commitizen-tools/commitizen

Description: Description Closes #466. Why cz_customize lets users define their own commit schema via changelog_pattern, change_type_order, and change_type_map — all the ingredients for a grouped changelog. However, until now, running cz changelog with those settings produced a single flat bullet list with no ### Feat / ### Fix headings, making the feature effectively unusable without an extra, non-obvious step. The root cause is the commit_parser default inherited from BaseCommitizen. BaseCommitizen.commit_parser is r"(?P.*)" (commitizen/cz/base.py:58) — a catch-all with no change_type named group. The changelog generator in commitizen/changelog.py:195 calls msg.pop("change_type", None) to key commits into sections; without that group, every commit yields change_type = None and lands in an ungrouped bucket (changelog.py:198). A maintainer confirmed the gap in December 2021 (issue comment by @woile): "I think the commit_parser regex is not exposed in the customize… and it looks like the customize is using the default from the base." Users who stumbled across the fix documented it in later comments — e.g. a community workaround posted in 2025 showing the exact four-group regex that had to be copy-pasted into every cz_customize config. Triage against master (v4.15.1) in #1964 verified the bug is still present: cz changelog --dry-run with changelog_pattern set still produces an ungrouped list. The fix gives CustomizeCommitsCz its own commit_parser class attribute — a conventional-commits-shaped default that works for any schema following the [(scope)][!]: convention — so users who only set changelog_pattern get grouping for free. What changed File Change commitizen/cz/customize/customize.py Added commit_parser class attribute (conventional-commits-shaped default with change_type, scope, breaking, and message named groups) tests/test_cz_customize.py Added test_commit_parser_default_extracts_change_type — regression test verifying all four named groups are extracted without any customize.commit_parser config key How it works The new class-level attribute (commitizen/cz/customize/customize.py:32–45 after the PR is applied) sits between the existing change_type_order default and __init__. It is a four-group regex: commit_parser = ( r"^(?P\w+)" r"(?:\((?P[^()\r\n]*)\))?" r"(?P!)?:\s*(?P.*)$" ) The __init__ override loop (commitizen/cz/customize/customize.py:40–50) already iterates over "commit_parser" and calls setattr if the user provided their own value. The class-level default is therefore transparently superseded by any customize.commit_parser key — zero behaviour change for existing configs that already set one. Why \w+ instead of a fixed alternation? cz_customize is format-agnostic: it cannot know which types a project has defined. Hard-coding feat|fix|chore|… would silently drop commits whose types aren't in the list. \w+ captures any single-token type, which matches every conventional-commits derivative. An alternative — deriving the alternation from changelog_pattern at runtime — was considered but is fragile: changelog_pattern is a broad filter regex, not a structured grammar, so parsing it reliably would require a regex-of-regexes approach. Why not just document "set commit_parser yourself"? The three other customisable attributes (changelog_pattern, change_type_order, change_type_map) all have sensible inherited defaults; a user who sets only those reasonably expects changelog grouping to work. generate_tree_from_commits (commitizen/changelog.py:92–171) compiles commit_parser with re.MULTILINE and calls map_pat.match(commit.message) per commit. process_commit_message (changelog.py:174–198) then calls parsed.groupdict() — so the named groups flow directly into the changes dict that drives section headings. Backward compatibility Users who already set customize.commit_parser explicitly are unaffected — the __init__ loop (customize.py:40–50) overwrites the class default with their value via setattr. Users who rely on the old flat-list behaviour (i.e., intentionally omitted commit_parser knowing it would match everything to None) will now see headings. This is the desired fix; the old behaviour was a bug, not a feature. All 66 existing test_cz_customize.py tests still pass — the new default only changes what happens when no commit_parser is configured. BaseCommitizen.commit_parser (commitizen/cz/base.py:58) is unchanged; other built-in cz_* plugins are unaffected. Checklist I have read the contributing guidelines Was generative AI tooling used to co-author this PR? Yes (please specify the tool below) Generated-by: Claude following the guidelines Code Changes Add test cases to all the changes you introduce Run uv run poe all locally to ensure this change passes linter check and tests Manually test the changes (see "Steps to Test" below) Update the documentation for the changes Expected Behavior Scenario Outcome cz_customize with changelog_pattern + change_type_order, no commit_parser key cz changelog --dry-run renders ### feat, ### fix, ### chore headings cz_customize with an explicit customize.commit_parser That custom regex is used unchanged — default is never applied Any other built-in cz_* (e.g. cz_conventional_commits) Unaffected; BaseCommitizen.commit_parser is unchanged cz_customize with commits that don't match the new default (e.g. ticket-123 do stuff) Commits still appear under change_type = None — same as before; changelog_pattern controls what's included Steps to Test This Pull Request git fetch fork fix/466-cz-customize-commit-parser-default git checkout fork/fix/466-cz-customize-commit-parser-default # 1. Targeted regression test. uv run pytest tests/test_cz_customize.py::test_commit_parser_default_extracts_change_type -v # 2. Reproduce the bug, then verify the fix. mkdir /tmp/cz466 && cd /tmp/cz466 git init -b main git config user.name test && git config user.email test@test.com cat > .cz.yaml << 'EOF' commitizen: name: cz_customize version: 0.1.0 customize: schema_pattern: '(feat|fix|chore)(\(\S+\))?!?:(\s.*)' changelog_pattern: '^(feat|fix|chore)(\(.+\))?(!)?' change_type_order: ["BREAKING CHANGE", "feat", "fix", "chore"] EOF git add .cz.yaml git commit -m "chore: initial" git commit --allow-empty -m "feat(DL-4567): new feature test" git commit --allow-empty -m "fix(DL-1234): qweqwe" git commit --allow-empty -m "chore: update deps" # Before the fix: flat list, no headings. # After the fix: grouped by ### feat / ### fix / ### chore. cz changelog --dry-run

Open Graph Description: Description Closes #466. Why cz_customize lets users define their own commit schema via changelog_pattern, change_type_order, and change_type_map — all the ingredients for a grouped changelog. Howe...

X Description: Description Closes #466. Why cz_customize lets users define their own commit schema via changelog_pattern, change_type_order, and change_type_map — all the ingredients for a grouped changelog. Howe...

Opengraph URL: https://github.com/commitizen-tools/commitizen/pull/1970

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width