grenadeandClaude Opus 5
29e4b08947
The runner is pnpm 11.24.0; this workstation is 10.30.3. The key was renamed across that major: pnpm 10 reads `onlyBuiltDependencies` (a list), pnpm 11 reads `allowBuilds` (a package -> bool map). Each ignores the other's key, which is why the runner kept reporting ignored builds while every local check passed. The diagnostic step found it in one run, after three failed guesses. `pnpm config get onlyBuiltDependencies` on the runner returned the list correctly, which was the misleading part -- the value resolved fine, it simply is not the key pnpm 11 consults. `pnpm approve-builds @swc/core esbuild` then wrote the pnpm 11 form and named it outright. Declares both keys so neither version is left out, rather than pinning the fleet to one. Verified by reproducing the failure locally under pnpm 11 (npx pnpm@11.24.0), then confirming install, lint and build pass under both 11.24.0 and 10.30.3. Drops the package.json `pnpm` field entirely: pnpm 11 warns it is no longer read for anything. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XZG2i4AmfSqE97EJGBVb64
19 lines
723 B
YAML
19 lines
723 B
YAML
# Dependencies permitted to run install scripts.
|
|
#
|
|
# Both fetch a platform-native binary and do not work without it; every other
|
|
# package in the tree stays denied, which is the point -- an install script is
|
|
# arbitrary code from a transitive dependency.
|
|
#
|
|
# Declared twice because the key was renamed between pnpm majors and the
|
|
# workstation and the CI runner do not carry the same one: pnpm 10 reads
|
|
# `onlyBuiltDependencies` (a list), pnpm 11 reads `allowBuilds` (a map). Each
|
|
# ignores the other's key, so both are listed rather than pinning the fleet to
|
|
# one version. `pnpm approve-builds` writes the pnpm 11 form.
|
|
allowBuilds:
|
|
'@swc/core': true
|
|
esbuild: true
|
|
|
|
onlyBuiltDependencies:
|
|
- '@swc/core'
|
|
- esbuild
|