ci: align npm-publish.yml with node-red-standards 0.6.0 - #50
Merged
Conversation
This repo is where the tag-driven model came from -- reviewing it during the pin cleanup is what led to node-red-standards issue #2, and the standard adopted this design rather than overwriting it. So no behaviour change: `git push --tags` published before and publishes now. Four details change. 1. Pre-releases no longer reach `latest`. The workflow ran a plain `npm publish` with no dist-tag handling, so a tag like v0.3.0-beta.1 would have moved the `latest` dist-tag onto a pre-release and pushed it to every install, Manage Palette included. `latest` cannot be walked back by publishing, only by a separate dist-tag change. A semver pre-release now goes to `beta` and the GitHub release is marked accordingly. 2. The publish job moves from Node 20 to 22.x. This repo depends on node-red ^5.0.1 and node-red@5 requires >=22.9, so a 20 pin pointed the wrong way against its own dependency floor. 3. verify fails when the tag disagrees with package.json. npm publishes the manifest version, not the tag name, so a mismatch publishes the wrong number under a tag that lies about it and burns the intended one for good. 4. `gh release create` replaces softprops/action-gh-release. gh is preinstalled on the runners, and a workflow holding an npm publish token is worth a few lines of shell to keep its action list official. The step is idempotent now -- the publish before it cannot be repeated. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Adopts
npm-publish.ymlfrom node-red-standards 0.6.0 (issue #2).This repo is where the model came from. It has been tag-driven since before the standard existed, and reviewing it for the pin cleanup is what led to #2 — the standard adopted this repo's design rather than overwriting it. So there is no behaviour change here:
git push --tagspublished before and publishes now. What changes are four details.1. Pre-releases no longer reach
latest— the important oneThe workflow here ran a plain
npm publishwith no dist-tag handling at all. A tag likev0.3.0-beta.1would therefore have moved thelatestdist-tag onto a pre-release and pushed it to every install, including everyone on Manage Palette.latestcannot be walked back by publishing, only by a separate dist-tag change.Now a semver pre-release (anything after a
-) publishes tobetaand marks the GitHub release as a pre-release.2. The publish job moves from Node 20 to 22.x
This repo depends on
node-red ^5.0.1, and node-red@5 requires Node>=22.9. Pinning 20 for the publish job was inconsistent with its own dependency floor — an EBADENGINE warning today rather than a failure, but pointed the wrong way. The template pin exists for exactly this case: it must satisfy the strictestengines.nodeamong consuming repos, not the standard's own>=20baseline.3. New: the tag must agree with
package.jsonnpm publishes the manifest version, not the tag name — so
git tag v0.2.13on a commit that still says0.2.12publishes 0.2.12 under a tag that lies about it, and burns 0.2.13 for good, since a version cannot be published twice.verifycompares the two and fails before anything reaches the registry.4.
gh release createinstead ofsoftprops/action-gh-releaseghis preinstalled on the runners. A workflow that ships into every repo and holds an npm publish token is worth a few lines of shell to keep its action list to the official ones. The step is also idempotent now — the publish before it cannot be repeated, so a re-run must not fail on a release that already exists.The job names change (
test→verify) and the gate now runs the same matrix as CI, which it already did here.