fix: all-stable notes toolchain — the PAIR is what matters, not the version #11
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/all-stable-notes-toolchain"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every release through the composite path fails on a guard demanding release-notes-generator@>=15. That version does not exist as a stable release: npm `latest` is 14.1.1, and the only >=15 is 15.0.0-beta.2. The guard was unsatisfiable without shipping a beta in the package that decides every repo's version numbers — the anti-pattern this estate already bans three times over (never @next, never @latest, homelab-cluster ADR-0047). Empty notes are a PAIR mismatch, not an out-of-date generator: generator 14 (Handlebars writer v8) + preset 9 -> renders <- shipped here generator 15 (function writer v9) + preset 10 -> renders generator 14 + preset 10 -> SILENT empty notes So the fix pins the preset DOWN to ^9.3.1 rather than chasing a beta. The resulting set is exactly what semantic-release 25.0.9 itself declares (commit-analyzer ^13.0.1, release-notes-generator ^14.1.0): the betas had been pinned ahead of the host, which is the only reason plugin overrides existed. The guard is now pair-aware and names the sanctioned resolution, so it cannot fire forever at something nobody can install. TWO BUGS IN THE GUARD, both found by testing it, both fatal to its purpose: - It resolved versions via require.resolve. Preset v10 and generator 15 are ESM-only, so CJS resolution throws ERR_PACKAGE_PATH_NOT_EXPORTED and the try/catch reported "compatible" for the exact pair it exists to catch — verified silent on 14+10. Lookup now walks node_modules on disk. - Resolution still starts from semantic-release's own directory, because npm hoisting can leave a good copy at the root and a bad one nested where semantic-release actually looks. Both directions proven in a scratch install: silent on 14+9, throws on 14+10. UNTOUCHED: the got/tar/gitea-globby overrides. Those are ce07256's fix for @saithodev/semantic-release-gitea declaring got ^10 (2020) — unrelated to the beta line, and I nearly deleted them assuming they were the same apparatus. RESTORED: the explicit `release: false` rules that published 1.2.3 dropped. Behaviourally identical to the analyzer defaults today, but this change also moves the preset across a major version, and "what does not cut a release" should not depend on another package's defaults while that package is moving. TRACEABILITY: published 1.2.3 has no commit in this repository — its release push-back was lost, so main (1.2.2) never contained the guard that is live in every consumer. This commit takes 1.2.3's published index.cjs as its base so the fix cannot silently delete it, and 1.2.3's undocumented divergences from main are called out above rather than absorbed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>1.2.3 was published to the Forgejo npm registry while its version-bump push-back never landed, so main stayed at 1.2.2 with no trace of it. Every consumer resolved `@webgrip/semantic-release-config@1` to code that existed in no commit — including a load-time guard nobody could read, review or git-blame, which then blocked every release in the org. It surfaced only because someone diffed the published tarball against main while debugging something else. Nothing was watching for that. Now something is: after the publish, compare the version the registry serves against origin/main's package.json, and warn when they disagree and the published tag is not an ancestor of main. Fail-SOFT deliberately. The publish has already happened; failing the job cannot un-publish it, and the push-back retry loops are what this observes rather than fights. A :⚠️: in the run that caused the divergence is the whole job. Three shapes verified against a scratch repo: agree -> silent; published-but- untracked (the real 1.2.3 shape) -> warns; bump landed later under a newer version with the tag an ancestor of main -> silent, no false positive. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Closed in favour of #12, which keeps this PR's guard rewrite (pair check + disk-based version lookup) and drops the rest. Dropped: the 1.2.3 -> 1.2.2 version downgrade and the engines downgrade, both built on my false finding that 1.2.3 had no commit on main (it does —
184967d, an ancestor of main, from #10; my clone was 17 days stale and a git fetch had failed silently); the re-added { type: 'chore', release: false } rules, which are a real regression, since compareReleaseTypes ranks false at -1 above major and one matching false rule vetoes every positive rule — that is why chore(deps) never released between 1.0.0 and 1.2.3; and the all-stable dependency swap, since the owner has re-confirmed the generator 15 + preset 10 design. Full rationale and the measured render matrix are in #12. The composite-side blocker this was chasing is fixed in webgrip/infrastructure#133.Pull request closed