fix: track stable yarn, with the lockfile on the same version

[bludot]

Follow-up to #4, taking the route you asked for: keep tracking stable Yarn, and move packageManager and the lockfile onto it so the two agree.

#4 unblocked releases (thanks — v1.2.0 shipped, which carried #3 out with it) by pinning CI to the version packageManager names. That works, but it means the project sits on 4.13.0 indefinitely. This does the opposite: restores yarn set version stable and brings everything else up to meet it.

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 with different resolve patch hashes. Immutable installs refused, and nothing released for four months.

Both are 4.18.0 now.

Diff

.github/workflows/semantic-release.yml | 10 +++---
.yarnrc.yml                            |  7 +++++
package.json                           |  2 +-
yarn.lock                              | 10 +++---

The lockfile change is 5 lines — the metadata version and two resolve patch hashes/checksums. Nothing was upgraded, added, or removed; no dependency resolution changed.

One thing worth a second look

Yarn 4.18 changed some defaults and wrote three settings into .yarnrc.yml to preserve this project's existing behaviour:

approvedGitRepositories:
  - "**"
enableScripts: true
npmMinimalAgeGate: 0

enableScripts is genuinely required — esbuild, @parcel/watcher and fontawesome all rebuild on install. The other two loosen new supply-chain protections (npmMinimalAgeGate blocks very recently published packages; approvedGitRepositories gates git dependencies). Committed as generated so this PR changes only what it claims to, but they are worth tightening deliberately rather than inheriting silently.

The tradeoff, stated plainly

A floating toolchain drifts again whenever Yarn changes the lockfile format — this PR fixes today's mismatch, it does not prevent the next one. If you want stable-tracking and immunity, the one-line version is yarn install --no-immutable, which lets Yarn rewrite the lockfile in-process instead of failing. That trades away lockfile enforcement in CI. Happy to add it if you want it; not assuming.

Verified locally

• CI=true yarn install --immutable under 4.18.0: exit 0, lockfile untouched
• yarn build: clean
• yarn set version stable resolves to 4.18.0 today, matching what is committed

🤖 Generated with Claude Code

[bludot]

🎉 This PR is included in version 1.2.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀