API surface changes documented
Why it matters
Published libraries without a changelog force consumers to diff two arbitrary git SHAs to understand what changed between versions — or to discover breaking changes at runtime after an upgrade. ISO 25010:2011 §6.5.2 classifies undocumented API surface changes as a maintainability defect. For internal applications this is low priority, but any package with "private": false or published "exports" fields is making an implicit promise to consumers that it does not keep when it ships breaking changes silently.
Severity rationale
Info because missing changelog documentation does not affect runtime behavior but removes the audit trail that lets consumers make informed upgrade decisions for published libraries.
Remediation
Add a CHANGELOG.md at the repo root following the Keep a Changelog format. Include a "Breaking Changes" section for any major or minor releases that remove or modify public API behavior.
# Changelog
## [Unreleased]
## [1.2.0] - 2024-03-15
### Added
- New `formatCurrency` utility function
### Changed
- `parseDate` now returns `null` instead of throwing on invalid input
### Breaking Changes
- Removed deprecated `formatMoney` function; use `formatCurrency` instead
Consider release-please or standard-version to generate changelog entries automatically from conventional commits.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Code Quality Essentials Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability.analysability — Maintainability — Analysability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from code-quality-essentials·automated