Skip to content

feat(config): add strict_config to reject unknown configuration keys - #2081

Closed
Manny7717 wants to merge 2 commits into
commitizen-tools:masterfrom
Manny7717:feat/strict-config
Closed

feat(config): add strict_config to reject unknown configuration keys#2081
Manny7717 wants to merge 2 commits into
commitizen-tools:masterfrom
Manny7717:feat/strict-config

Conversation

@Manny7717

Copy link
Copy Markdown

Description

Closes #300.

Adds a new strict_config configuration option (default false). When enabled, Commitizen rejects unknown top-level keys in the [tool.commitizen] (or commitizen) section of the configuration file with an InvalidConfigurationError listing the offending keys — the same spirit as pytest's --strict-markers. This makes typos like bump_mesage fail loudly instead of being silently ignored.

Changes:

  • Settings TypedDict + DEFAULT_SETTINGS: new strict_config key
  • BaseConfig._check_unknown_keys(): validates parsed top-level keys against the known settings (derived from the Settings TypedDict, plus annotated_tag_message which predates the TypedDict)
  • TOML, JSON and YAML parsers now call the check after loading their section
  • Docs: new strict_config section in docs/config/option.md and a category entry in configuration_file.md
  • Tests: parametrized over TOML/JSON/YAML for reject-on-unknown, plus allow-when-disabled and accept-known-keys cases

Keys nested under customize and extras are plugin-owned and deliberately not checked.

Checklist

Was generative AI tooling used to co-author this PR?

  • Yes (please specify the tool below)

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 (ruff check, ruff format --check, mypy, full pytest suite — see below)
  • Manually test the changes:
    • Verified the feature works as expected: strict_config = true + typo'd key → InvalidConfigurationError naming the key; same config without strict_config → loads normally; valid keys with strict mode on → loads normally
    • Tested edge cases: all three config formats (TOML/JSON/YAML), missing commitizen section, annotated_tag_message (consumed but not in the TypedDict) accepted
    • Backward compatibility maintained: option defaults to false, so existing configurations are unaffected
  • Update the documentation for the changes

Tests

  • Full suite: 1314 passed, 2 xfailed (uv run pytest -n auto)
  • ruff check clean, ruff format --check clean, mypy commitizen/ clean
When enabled, unknown top-level keys in the [tool.commitizen] section
(e.g. a typo like 'bump_mesage') raise InvalidConfigurationError instead
of being silently ignored. Mirrors pytest's --strict-markers.

- Add strict_config setting (default False) to Settings/DEFAULT_SETTINGS
- Validate parsed keys against known settings in BaseConfig
- Wire the check into the TOML, JSON and YAML config parsers
- Document the option and add regression tests

Closes commitizen-tools#300
@codecov

codecov Bot commented Aug 28, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.27%. Comparing base (d914b4d) to head (8998b55).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2081      +/-   ##
==========================================
+ Coverage   98.19%   98.27%   +0.07%     
==========================================
  Files          61       61              
  Lines        2829     2844      +15     
==========================================
+ Hits         2778     2795      +17     
+ Misses         51       49       -2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

@Manny7717

Copy link
Copy Markdown
Author

Closing this as a duplicate of #1961 (bearomorphism), which predates it (opened May 9) and implements the same strict_config mechanism for issue #300 — including the warn-by-default + strict opt-in behavior agreed in the issue discussion. Two PRs on the same feature would split the review queue, so I'm withdrawing mine to keep things clean. My implementation (strict-only variant, 21/21 CI green) remains available on the feat/strict-config branch of my fork if any part of it is useful.

@Manny7717 Manny7717 closed this Aug 30, 2026
@Manny7717
Manny7717 deleted the feat/strict-config branch August 30, 2026 14:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1 participant