Repository navigation
fix: upgrade to yarn 4.18 and regenerate the lockfile - #4
Merged
Merged
Conversation
Semantic Release has failed on every push to main since April, so nothing
has been released since 1.1.0 — including the last three merged PRs.
The install step ran `yarn set version stable`, which fetches whatever
Yarn is newest at build time regardless of the `packageManager` field.
That is now 4.18.0, while the repo pins 4.13.0 and the committed
yarn.lock is the v8 format 4.13 writes. 4.18 wants to rewrite it to v10
with different patch hashes, and an immutable install refuses:
YN0028: The lockfile would have been modified by this install,
which is explicitly forbidden.
Nothing in the repo changed to cause this — Yarn shipped a release, and
an unpinned toolchain picked it up.
Corepack already installs the version `packageManager` names, so drop the
override and let it. `--immutable` is now explicit rather than implied by
CI detection, matching weeb-frontend, whose releases have kept working
precisely because it never floated.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
🎉 This PR is included in version 1.2.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
bludot
changed the title
bludot
added a commit
that referenced
this pull request
Aug 16, 2026
#4 unblocked releases by pinning CI to the version packageManager names. This takes the other route deliberately: keep tracking the newest stable Yarn, and move packageManager and the lockfile onto it so the two agree. The failure was never that stable moved — it was that only CI followed. package.json said 4.13.0 and the lockfile was the v8 format 4.13 writes, while `yarn set version stable` had reached 4.18.0, which rewrites it to v10. Immutable installs refused, and nothing released for four months. Both are now 4.18.0. The lockfile diff is five lines — the metadata version and two resolve patch hashes. No dependency resolution changed. Yarn 4.18 also wrote three settings into .yarnrc.yml to preserve existing behaviour across its new defaults. enableScripts is required here, as esbuild, @parcel/watcher and fontawesome all rebuild on install. npmMinimalAgeGate and approvedGitRepositories are the loosened ones and are worth revisiting separately. Co-authored-by: Claude Opus 5 (1M context) <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.
Semantic Release has failed on every push to main since April. Nothing has been released since
v1.1.0— including the last three merged PRs. The image-key change is sitting on main undeployed.Cause
CI runs
yarn set version stable, which tracks whatever Yarn is newest at build time. That is now 4.18.0, whilepackage.jsonpinned 4.13.0 and the committed lockfile was the v8 format 4.13 writes. 4.18 rewrites it to v10 with differentresolvepatch hashes, and the install refuses.Nothing in the repo changed to cause this — Yarn shipped a release and the floating toolchain picked it up. That is why it first broke on a commit that had nothing to do with dependencies.
Fix: move to stable, not away from it
packageManageris nowyarn@4.18.0and the lockfile is regenerated to match, so CI'syarn set version stablelands on exactly what is committed. The workflow is untouched.The lockfile diff is 5 lines: the metadata version and two
resolvepatch hashes/checksums. No dependency resolution changed — nothing was upgraded, added, or removed.One thing worth a second look
Yarn 4.18 changed some defaults and wrote three settings into
.yarnrc.ymlto preserve this project's existing behaviour:enableScriptsis genuinely required — esbuild,@parcel/watcherand fontawesome all rebuild on install. The other two loosen new supply-chain protections (npmMinimalAgeGateblocks very recently published packages;approvedGitRepositoriesgates git dependencies). Committed as generated so this PR changes only what it claims to, but they are worth tightening in a follow-up rather than inheriting silently.Verified locally
CI=true yarn install --immutableunder 4.18.0: exit 0, lockfile untouchedyarn build: cleanyarn set version stableresolves to 4.18.0 today, matching what is now committedNote on recurrence
A floating toolchain will drift again whenever Yarn changes the lockfile format. If that becomes annoying, the one-line hardening is
--no-immutableon the CI install, which keeps stable tracking while letting the lockfile be rewritten in-process. Not doing that here.🤖 Generated with Claude Code