fix(web): pnpm 11 renamed the build allowlist to allowBuilds
deploy / build-web (push) Successful in 1m36s
deploy / build (push) Successful in 6m26s
deploy / deploy (push) Successful in 18s
deploy / deploy-web (push) Failing after 13s

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
This commit is contained in:
2026-08-31 13:32:23 +03:00
co-authored by Claude Opus 5
parent 78d35cfd29
commit 29e4b08947
4 changed files with 24 additions and 22 deletions
+5 -4
View File
@@ -33,10 +33,11 @@ jobs:
steps:
- uses: actions/checkout@v4
# The runner's pnpm is not necessarily the workstation's, and this
# setting moved location between 10.x releases. Print what it actually
# resolves to, so a failure here is diagnosable from the log rather than
# by pushing another guess.
# The runner's pnpm is not the workstation's -- 11.x here against 10.x
# there at the time of writing -- and the build-script allowlist was
# renamed between those majors. Printing the version and the resolved
# settings is what turned three failed guesses into a one-line answer,
# so it stays.
- name: pnpm environment
working-directory: web
run: |
+5 -4
View File
@@ -61,10 +61,11 @@ jobs:
# The gate for the frontend, matching the Rust one: a type error or a
# lint failure must not reach a host either.
# The runner's pnpm is not necessarily the workstation's, and this
# setting moved location between 10.x releases. Print what it actually
# resolves to, so a failure here is diagnosable from the log rather than
# by pushing another guess.
# The runner's pnpm is not the workstation's -- 11.x here against 10.x
# there at the time of writing -- and the build-script allowlist was
# renamed between those majors. Printing the version and the resolved
# settings is what turned three failed guesses into a one-line answer,
# so it stays.
- name: pnpm environment
working-directory: web
run: |
-6
View File
@@ -32,11 +32,5 @@
"typescript": "^5.9.3",
"typescript-eslint": "^8.46.2",
"vite": "^7.2.2"
},
"pnpm": {
"onlyBuiltDependencies": [
"@swc/core",
"esbuild"
]
}
}
+14 -8
View File
@@ -1,12 +1,18 @@
# The allowlist of dependencies permitted to run install scripts. Both fetch a
# platform-native binary; every other package in the tree is denied, which is
# the point -- an install script is arbitrary code from a transitive dependency.
# Dependencies permitted to run install scripts.
#
# Declared here *and* in package.json's `pnpm` field on purpose: pnpm moved
# this setting between 10.x releases, and the workstation and the CI runner do
# not carry the same version. Whichever one is authoritative, it finds the same
# list, and the duplication is four lines against a failure that only shows up
# on the runner.
# 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