feat: promote npm edge tag to latest when prerelease is promoted

[AaronFeledy]

Problem

When a release is published as a prerelease, it gets tagged as edge on npm. Later, when the release is promoted to a full release in GitHub, the npm latest tag doesn't update because the workflow only triggered on published.

Solution

• Added released to the release workflow trigger types
• New lightweight promote job that only runs npm dist-tag add latest — no install, no lint, no tests, no re-publish
• Only fires on the released event (when a prerelease is promoted to full release)
• Existing deploy job is now explicitly gated to published events only (no behavior change)
• Uses TAG_NAME env var instead of direct interpolation to prevent script injection

Flow

1. Publish as prerelease → full pipeline runs, publishes with edge tag (unchanged)
2. Promote release → uncheck prerelease → promote job runs, points latest to that version (~15s)

The dist-tag add command is idempotent, so if both published and released fire on a fresh non-prerelease publish, the redundant promote is harmless.

---

Note

Low Risk
CI-only change that adjusts GitHub Actions triggers and npm dist-tagging; main risk is accidentally retagging the wrong version if release tags are misconfigured.

Overview
Updates the release GitHub Action to also trigger on release.released events (in addition to published).

Adds a lightweight promote job that runs only on released to retag the package version from the GitHub release tag as npm latest via npm dist-tag add, and gates the existing deploy publish pipeline to run only on published.

^{Written by Cursor Bugbot for commit 2ab3551. This will update automatically on new commits. Configure here.}

[netlify]

❌ Deploy Preview for lando-mailpit failed. Why did it fail? →

Name	Link
🔨 Latest commit	2ab3551
🔍 Latest deploy log	https://app.netlify.com/projects/lando-mailpit/deploys/6997db8bc6837f00097b44f3

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is ON. A Cloud Agent has been kicked off to fix the reported issues.}

[cursor]

Inconsistent action versions between workflow jobs

Low Severity

The new promote job uses actions/checkout@v6 and actions/setup-node@v6, while the existing deploy job in the same workflow uses @v4 for both. Having two different major versions of the same actions in one workflow file creates a maintenance inconsistency and can confuse future contributors about which version is canonical. Since setup-node v6 has breaking changes (removed always-auth, changed caching defaults), the version split makes it harder to reason about behavior across jobs.

Additional Locations (1)

• .github/workflows/release.yml#L44-L47

 

[cursor]

Race condition causes promote job to fail on non-prerelease publishes

Medium Severity

When a fresh non-prerelease is published, both published and released events fire, creating two separate concurrent workflow runs. The promote job (~15 seconds) completes long before the deploy job (~3+ minutes) reaches npm publish. Since npm dist-tag add fails with a 404 when the version doesn't exist on the registry yet, the promote job will error out on every fresh non-prerelease publish. The PR description claims this scenario is "harmless" and "idempotent," but the job actually fails. While functionally the deploy job still publishes to latest correctly, the persistent red X creates noise and can desensitize maintainers to real promote failures.