Area
Build, CI, or release tooling
Steps to reproduce
- Check out
main at any commit from 2026-09-12 onward.
- Run the Release Smoke job's command:
node scripts/release-smoke.ts.
The failure is not specific to a commit, a runner, or an OS. It reproduces on GitHub-hosted runners as well as the usual CI runners, and needs no local state.
Expected behavior
release-smoke.ts regenerates a lockfile from scratch and the smoke check passes, as it did through 2026-09-12 07:45 UTC.
Actual behavior
The Release Smoke job fails while regenerating the lockfile:
[ERR_PNPM_UNUSED_PATCH] The following patches were not used: expo-audio@57.0.4
Either remove them from "patchedDependencies" or update them to match packages in your dependencies.
Error: Command failed: vp install --lockfile-only --ignore-scripts
CI on main has been red since then. The cause is a version-pin mismatch that only surfaces on fresh resolution:
pnpm-workspace.yaml keys the patch to the exact version expo-audio@57.0.4.
apps/mobile/package.json declares the range "expo-audio": "~57.0.4".
scripts/release-smoke.ts deletes pnpm-lock.yaml before running vp install --lockfile-only, so resolution ignores the committed lockfile.
expo-audio@57.0.5 was published to npm on 2026-09-11, so the range now resolves to 57.0.5 and the exact-version patch key matches nothing.
Ordinary installs still succeed because the committed lockfile continues to pin 57.0.4. Only the lockfile-regenerating path sees the newer version.
Two things worth noting:
- No repository change caused this. The only commit between the last green run and the first red one is an unrelated UI change that touches no dependency file, patch, or lockfile. The break came from a package being published.
- Every exact-version patch pin has the same shape.
pnpm-workspace.yaml currently pins 12 patches to exact versions while the corresponding dependencies are declared as ranges, so any of them can break this job the next time upstream publishes a matching patch release. expo-audio is just the first to fire. A fix that only bumps this one entry will hold until the next publish.
Impact
Major degradation or frequent failure
Version or commit
main @ d1d15c6 (first observed red; still reproducing)
Environment
Ubuntu 24.04, Node 24.21.0. Not OS- or runner-specific.
Logs or stack traces
[ERR_PNPM_UNUSED_PATCH] The following patches were not used: expo-audio@57.0.4
Either remove them from "patchedDependencies" or update them to match packages in your dependencies.
Error: Command failed: vp install --lockfile-only --ignore-scripts
at genericNodeError (node:internal/errors:986:15)
at wrappedFn (node:internal/errors:540:14)
at checkExecSyncError (node:child_process:942:11)
at Module.execFileSync (node:child_process:978:15)
at file:///home/runner/work/t3code/t3code/scripts/release-smoke.ts:209:20
status: 1
Workaround
None that keeps the check meaningful. Re-running the job does not help, since the resolution is deterministic now that 57.0.5 is published.
Area
Build, CI, or release tooling
Steps to reproduce
mainat any commit from 2026-09-12 onward.node scripts/release-smoke.ts.The failure is not specific to a commit, a runner, or an OS. It reproduces on GitHub-hosted runners as well as the usual CI runners, and needs no local state.
Expected behavior
release-smoke.tsregenerates a lockfile from scratch and the smoke check passes, as it did through 2026-09-12 07:45 UTC.Actual behavior
The Release Smoke job fails while regenerating the lockfile:
CI on
mainhas been red since then. The cause is a version-pin mismatch that only surfaces on fresh resolution:pnpm-workspace.yamlkeys the patch to the exact versionexpo-audio@57.0.4.apps/mobile/package.jsondeclares the range"expo-audio": "~57.0.4".scripts/release-smoke.tsdeletespnpm-lock.yamlbefore runningvp install --lockfile-only, so resolution ignores the committed lockfile.expo-audio@57.0.5was published to npm on 2026-09-11, so the range now resolves to 57.0.5 and the exact-version patch key matches nothing.Ordinary installs still succeed because the committed lockfile continues to pin 57.0.4. Only the lockfile-regenerating path sees the newer version.
Two things worth noting:
pnpm-workspace.yamlcurrently pins 12 patches to exact versions while the corresponding dependencies are declared as ranges, so any of them can break this job the next time upstream publishes a matching patch release.expo-audiois just the first to fire. A fix that only bumps this one entry will hold until the next publish.Impact
Major degradation or frequent failure
Version or commit
main @ d1d15c6 (first observed red; still reproducing)
Environment
Ubuntu 24.04, Node 24.21.0. Not OS- or runner-specific.
Logs or stack traces
Workaround
None that keeps the check meaningful. Re-running the job does not help, since the resolution is deterministic now that 57.0.5 is published.