Repository navigation
fix: list every commit type in the release notes and CHANGELOG.md - #128
Merged
Merged
Conversation
The angular preset's transform returns undefined for every type except feat, fix, perf and revert, so a release made of refactor, docs, test, build, ci, style or chore commits published a version header and nothing under it. The notes now keep the preset's templates and replace its transform: each type in commitTypes gets a section titled from the same table, in the table's order, and chore(release) commits are left out. The header pattern accepts a `!` after the type, as the commit analyser's does, so a breaking `feat!:` commit is read the same way in both. The conventionalcommits preset stays rejected: its templates are functions, which the conventional-changelog-writer bundled with the release-notes generator does not call, so its output has section titles with no commits under them. The release-notes generator becomes a direct devDependency so tests can run it.
The test builds the notes through @semantic-release/release-notes-generator with the options in release.config.ts, and asserts the exact notes for one commit of every type, a release made of types the angular preset hides, a breaking change, issue and mention links, a release commit in the range, and commits that are not conventional commits. tsconfig.json now includes root test files and declaration files so the test is type-checked and linted beside release.config.ts.
Each version's entry is rebuilt from its tag range by the release-notes configuration in release.config.ts, so releases whose commits were all of a type the angular preset hid now list them, and every earlier commit is carried over. Sections follow the order of commitTypes.
Mearman
marked this pull request as ready for review
October 10, 2026 06:30
Member
Author
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
|
🎉 This PR is included in version 2.36.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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.
Releases made only of
refactor,test,docs,choreand similar commits published notes and a CHANGELOG.md entry with a version header and nothing under it. The angular preset's writer returnsundefinedfor every type except feat, fix, perf and revert (and commits with a breaking change), andrelease.config.tsbumps the version for all of them.The notes now keep the angular preset's templates and heading style, and
release.config.tsreplaces its commit transform. Every type incommitTypesis listed under atitlekept in the same table, in the table's order: Features, Bug Fixes, Performance Improvements, Reverts, Code Refactoring, Documentation, Styles, Tests, Build System, Continuous Integration, Chores.chore(release)commits are skipped, which matters for a range read by hand since it contains earlier release commits. Dependabot'schore(deps)andbuild(deps)commits appear. The parser also acceptsfeat!:the way commit-analyzer's preset does; the angular header pattern did not, so such a commit would have been dropped from the notes.I tried the
conventionalcommitspreset first, since the comment in the config said it did not render. With conventional-changelog-conventionalcommits 10.2.1 under the writer 8.4.0 that @semantic-release/release-notes-generator 14.1.1 bundles it still does not: the preset's templates are functions, the writer registers them as Handlebars partials and calls them with the wrong arguments, so a release gets its section titles and no commits under them. It is also not resolvable from the repository root without a new dependency. The comment in the config is updated to say what was checked.The generator is now a direct devDependency so
release.config.unit.test.tscan run the real generator against the options inrelease.config.ts. Run against the config on main, five of its eight cases fail (header-only notes, no Tests section and so on); the other three pass on both.Dry run of the generator with this config over the real ranges v2.36.3..v2.36.4 and v2.36.0..v2.36.1 gives v2.36.4 a body with its refactor, test and chore(deps) commits, and v2.36.1 a body with its one chore(deps-dev) commit; both were header-only before.
CHANGELOG.mdis regenerated tag by tag with the same code (own commit). Every commit that was in an old entry is still there; the old entries are a subset of the new ones. One entry changes shape rather than content: v2.0.0 listedfeat!: make the type-checked bundle ...as an untyped bullet, and it is now under Features without the prefix. Sections within an entry are now incommitTypesorder instead of alphabetical, so Features comes before Bug Fixes. Some historic commit bodies in the file contain a spaced double hyphen that is carried over verbatim from the original messages.The bodies of the existing GitHub releases are not changed by this PR; they need to be updated separately once it is merged.
Refs #127