ci(release): skip throwaway workspace update during staggered release - #3384
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d007559677
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| # though a non-pre 6.2.0 would satisfy it. Relax peer resolution for this | ||
| # throwaway resolve only; the published manifests still carry the correct peer | ||
| # ranges written by each package's release-it bumper. | ||
| NPM_CONFIG_LEGACY_PEER_DEPS: "true" |
There was a problem hiding this comment.
For prerelease/major releases this still leaves npm's workspace update enabled during each npm version run; npm documents workspaces-update as the update run after operations that can change workspace installs, while legacy-peer-deps only ignores peerDependencies. In this repo the later redis workspace still pins non-peer dependencies such as @redis/client: "6.1.0" until its own bumper runs, so after @redis/client is bumped first the release step can still try to resolve the old package from the registry or churn the lockfile despite this setting. If the resolve is meant to be throwaway, disable the workspace update for the release bump instead of only relaxing peer resolution.
Useful? React with 👍 / 👎.
The release workflow releases one workspace at a time, starting with @redis/client. `npm version` runs a workspace-update install after bumping the version; because the sibling packages still pin "@redis/client" to the pre-bump range until their own release-it bumpers run, that install fails with ERESOLVE. It is triggered by a pre-release bump (e.g. 6.2.0-beta.0), which semver excludes from a plain "^6.1.0" range even though a non-pre-release 6.2.0 would satisfy it. The post-bump install is throwaway — each package publishes from its own dist and each bumper writes the correct dependency/peer ranges at publish time — so set NPM_CONFIG_WORKSPACES_UPDATE=false to skip it. This avoids the resolve entirely, rather than relaxing peer checks (which would pull the stale client from the registry), and leaves the lockfile untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
d007559 to
bb47dbd
Compare
Problem
The release workflow releases one workspace at a time, starting with
@redis/client.npm versionruns a workspace-update install after bumping the version. Because the sibling packages still pin@redis/clientto the pre-bump range until their ownrelease-itbumpers run, that install fails withERESOLVE, aborting the release before anything is published or tagged.It surfaced on a pre-release beta minor (
6.1.0 → 6.2.0-beta.0): semver excludes a pre-release from a plain^6.1.0range (a pre-release only matches a range carrying a pre-release at the samemajor.minor.patch), even though a non-pre-release6.2.0would satisfy it.Reproduced locally with
npm version 6.2.0-beta.0 -w @redis/client→ ERESOLVE on the post-bump workspace update.Fix
Set
NPM_CONFIG_WORKSPACES_UPDATE=falseon the release step sonpm versionskips the post-bump workspace-update install. That install is throwaway — each package publishes from its owndist/, and eachrelease-itbumper writes the correct dependency/peer ranges at publish time.Verified locally:
npm version 6.2.0-beta.0 --workspaces-update=false -w @redis/clientcompletes with no ERESOLVE and leavespackage-lock.jsonuntouched.Why not
--legacy-peer-depslegacy-peer-depsalso clears the ERESOLVE, but it only ignorespeerDependencies— the laterredisworkspace still pins non-peer@redis/client: "6.1.0", so the resolve pulls the stale 6.1.0 client from the registry and churns the lockfile. Skipping the throwaway update avoids the resolve entirely instead of papering over it.Also fixes major releases
Same mechanism applies to a major bump (siblings pin
^6.x, client to7.0.0), so this unblocks that path too and removes the need for the manual peer-range widening previously used before a major.🤖 Generated with Claude Code