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
Workflow-only change that adjusts GitHub Actions triggers and npm dist-tagging; main risk is mis-tagging latest on release promotion.

Overview
Updates the NPM release workflow to also trigger on GitHub release events of type released (in addition to published).

Adds a new promote job that runs only on released to move the package version referenced by the release tag from edge to the npm latest dist-tag via npm dist-tag add, and gates the existing deploy job to run only on published events.

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

[netlify]

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

Name	Link
🔨 Latest commit	ef99a85
🔍 Latest deploy log	https://app.netlify.com/projects/lando-mssql/deploys/6997dc8b20365d0008719b08

[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 across jobs in same workflow

Low Severity

The new promote job uses actions/checkout@v6 and actions/setup-node@v6, while the deploy job in the same file and every other workflow in the repo consistently uses @v4. Mixing major versions within the same workflow file is surprising and increases maintenance burden. checkout@v6 also introduced credential-handling changes with known compatibility caveats, and setup-node@v6 enables npm caching by default (unnecessary here since no npm install runs).

 

[cursor]

Race condition: promote job runs before deploy publishes

Medium Severity

When a fresh non-prerelease is published, both published and released events can fire, creating two independent workflow runs. The promote job (~20s total) will attempt npm dist-tag add long before the deploy job (~2+ minutes) reaches its npm publish step. Since the version doesn't exist on npm yet, the npm dist-tag add command will fail. The PR description states this scenario is "harmless," but dist-tag add can only be idempotent if the version already exists on npm. The result is a failed workflow run on every non-prerelease publish that triggers both events.

Additional Locations (1)

• .github/workflows/release.yml#L4-L7