release: `revert:` commits would render nothing in the changelog

[IgorShevchik]

Environment

main @ 28677edf, release-please-config.json.

Description

changelog-sections replaces the preset's default type list rather than extending it. Every type absent from ours is therefore dropped entirely — not hidden, gone.

Ours lists nine types:

feat, fix, perf, docs, test, chore, ci, refactor, build

The default list, verified by reading DEFAULT_COMMIT_TYPES in conventional-changelog-conventionalcommits@10.3.0 (src/constants.js), marks five as visible and seven as hidden:

type	section	default
feat, feature	Features	visible (effect: 'bump')
fix	Bug Fixes	visible
perf	Performance Improvements	visible
revert	Reverts	visible
docs	Documentation	hidden
style	Styles	hidden
chore	Miscellaneous Chores	hidden
refactor	Code Refactoring	hidden
test	Tests	hidden
build	Build System	hidden
ci	Continuous Integration	hidden

Two of the five visible types — revert and feature — are not in our list, so they resolve to nothing at all.

Why revert is the one that matters

A revert is precisely the news a consumer of the package has to see: something that shipped has been taken back. It is visible in the default preset for that reason, and in our configuration it would print nothing.

The six hidden types we do list are deliberate and should stay — this changelog doubles as a porting log for the fork, so docs, test, chore, ci, refactor and build are wanted. That override is correct; it just took revert with it as collateral.

Not yet a live defect

git log shows zero revert: commits in this history, so nothing published so far is missing anything. The first one would have been silently absent, with no error anywhere — the changelog would simply not mention it.

style is a separate case, and fine as-is

style is hidden in the default preset, so listing it or omitting it produce the same empty output — no action needed. For the record it has 22 uses here, all between 2024-11-26 and 2024-12-09; the practice stopped and visual changes have since gone through feat:/fix:.

Suggested fix

Add the two missing visible types, in the preset's own order so Reverts lands after Performance and above the docs/tests/chore block:

         { "type": "feat", "section": "Features" },
+        { "type": "feature", "section": "Features" },
         { "type": "fix", "section": "Bug Fixes" },
         { "type": "perf", "section": "Performance" },
+        { "type": "revert", "section": "Reverts" },
         { "type": "docs", "section": "Docs" },

Additional context

Found while writing a setup guide for the release pipeline, when a claim about the preset's defaults turned out to be wrong on checking and the check surfaced this gap.

[IgorShevchik]

Three corrections to the description above

Five independent review passes over #435 found the fix correct and the reasoning around it wrong in three places. Recording them here so this issue does not stay the authoritative version of claims that are false.

1. Wrong preset version cited

The table above cites conventional-changelog-conventionalcommits@10.3.0, src/constants.js, DEFAULT_COMMIT_TYPES, and an effect: 'bump' | 'hidden' column. That package version is not what runs here.

release-please-action@v5.0.0 (the pinned SHA) resolves release-please@17.6.0, which pins conventional-changelog-conventionalcommits: ^6.0.0 → 6.1.0. Grepping the shipped dist/index.js at that SHA: DEFAULT_COMMIT_TYPES → 0 hits, effect: 'bump' → 0 hits.

In 6.1.0 there is no src/constants.js. The defaults are an inline array in writer-opts.js → defaultConfig(), and the visibility key is hidden: true, not effect.

Membership is identical across 6.x and 10.x — same twelve types, same five visible — so the fix is unaffected. But anyone re-deriving this from the cited file reads a package that is not installed, and writing "effect": "hidden" into release-please-config.json would be a silent no-op.

2. "Nothing published is missing anything" — right answer, broken reasoning

The count is correct: zero revert:-typed and zero feature: commits.

But two GitHub-style reverts exist and were shipped:

8b774dcd  2025-01-10  Revert "chore(deps): update `typescript`"
2cc874e2  2025-01-10  Revert "chore(deps): update `@nuxt/module-builder`"

Both are ancestors of main, both first released in v0.1.3, neither appears in CHANGELOG.md. So the sentence as written is false.

What actually saves the conclusion is something the description never says: both predate bootstrap-sha (ae76be29, 2026-08-06), and release-please-config.json only landed 2026-08-08. This config has produced exactly one release — 2.11.0 — and it contains no revert of any form.

3. The style rationale is backwards

style is hidden in the default preset, so listing it or omitting it produce the same empty output — no action needed.

Both halves are wrong, and this contradicts the paragraph above it, which correctly notes that the six default-hidden types we do list render visibly. CHANGELOG.md settles it: 58 ### Docs and 59 ### Chore headings, all default-hidden types made visible purely by being listed.

Listing and omitting differ twice:

• a listed entry arrives with no hidden flag, so it prints;
• an omitted type skips the if (entry) section rewrite in writer-opts.js, so a breaking commit of that type keeps its raw type string as the group title, and commitGroupOrder.indexOf() returns -1 — sorting it above Features:

### style
* a breaking style commit …

### Features
…

The decision to omit style still stands, but the general problem is not about style and is filed separately — twelve types in this history are unconfigured, playground (31) and doc (23) ahead of it. No live defect: all 30 breaking commits so far are of configured types.

---

Also worth recording, since it strengthens the case rather than weakening it: feature matters for a reason the description missed. DefaultVersioningStrategy bumps on type === 'feat' || type === 'feature' and never consults changelog-sections, so a feature: commit already cuts a minor release while contributing no changelog line.

---

Generated by Claude Code