fix(deps): pin the conventionalcommits preset to the line semantic-release supports - #616
Merged
Merged
Conversation
…lease supports The first app release attempt after the 1.0 graduation died in generateNotes: Missing helper: "conventional-changelog-conventionalcommits requires conventional-changelog-writer@9 or newer" semantic-release 25 bundles @semantic-release/release-notes-generator 14.1.1, which depends on conventional-changelog-writer ^8. The preset was at ^10.4.0, and the 10.x line pulls @conventional-changelog/template and requires writer 9 — so the preset and the generator could never agree. The 9.x line has no writer constraint at all and is the one that pairs with release-notes-generator 14. Verified with `semantic-release --dry-run`: generateNotes now completes and the run exits 0, where it previously aborted.
Contributor
Author
|
🎉 This PR is included in version 1.0.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
4 tasks
therealbrad
added a commit
that referenced
this pull request
Sep 8, 2026
#616 pinned conventional-changelog-conventionalcommits to ^9.3.1 to unbreak the release pipeline, and Dependabot immediately proposed ^10.4.0 again in the next dev-dependencies group (#620). Merging that would restore the exact failure #616 fixed: the 10.x line requires conventional-changelog-writer@9, semantic-release 25 bundles a generator depending on writer ^8, and generateNotes dies before any release is cut. The hold was missing from the batch added in #617 — an oversight, since #616 had pinned it minutes earlier.
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.
Description
The first app release attempt after the 1.0 graduation (run 34182722798) computed
1.0.1correctly and then died ingenerateNotes:semantic-release@25.0.9bundles@semantic-release/release-notes-generator@14.1.1, which depends onconventional-changelog-writer: ^8.0.0. The preset was pinned at^10.4.0, and the 10.x line pulls@conventional-changelog/templateand requires writer 9. The two could never agree, so no app release could be cut at all.The 9.x line declares no writer constraint (
compare-funcis its only dependency) and is the line that pairs withrelease-notes-generator@14. Pinned to^9.3.1.Related Issue
Blocks all app releases after v1.0.0.
Type of Change
How Has This Been Tested?
semantic-release --dry-run --no-cinow runs to completion:Previously the same command aborted at that step with the handlebars error above.
The lockfile delta is limited to the preset swap and dropping the
@conventional-changelog/templatetransitive that carried the writer-9 requirement. The package is a devDependency used only by the release pipeline, so no application code path is affected.Checklist
Additional Notes
Merging this will cut v1.0.1.
fix(deps)is configuredrelease: false, but thefix(helm)commit from #615 is already sitting onmainunreleased and is a patch-level change — so once the pipeline works, semantic-release will publish v1.0.1 containing the chart version bump. That is the intended outcome and doubles as end-to-end proof the fix holds.This mismatch arrived with the beta tree: the semantic-release plugin majors were taken on
beta(beta.10) and flagged at the time as unproven until the nextmainrelease. This was that release.