【pnpm】ERR_PNPM_IGNORED_BUILDS の直し方 — allowBuilds へ移行

pnpm 11以降でinstallがERR_PNPM_IGNORED_BUILDSで止まる原因と、廃止されたonlyBuiltDependenciesをallowBuildsへ移す手順を、v10とv12の実測結果つきで説明します。

この記事が解決する悩み

• pnpm を 11 以降に上げたら、それまで通っていた pnpm install が ERR_PNPM_IGNORED_BUILDS で止まるようになった
• 直そうとして package.json の pnpm.onlyBuiltDependencies を書き足しても、「そのキーはもう読んでいない」という警告が出るだけ
• 気づいたら pnpm-workspace.yaml に見覚えのない allowBuilds が追記されていて、コミットすべきか判断に迷う

対象読者: pnpm をチーム開発や CI で使っていて、v10 以前の設定をそのまま抱えている人
前提知識: package.json とロックファイルの基本、postinstall などのライフサイクルスクリプトが何をするか

結論

pnpm 11 で依存のビルド承認は allowBuilds に一本化され、既定は「未審査のスクリプトは実行せず、install は非0で終わる」です。

onlyBuiltDependencies / onlyBuiltDependenciesFile / neverBuiltDependencies / ignoredBuiltDependencies は廃止され、いまは読まれません。

最短の直し方は pnpm approve-builds にパッケージ名を渡す方法ですね。

$ pnpm approve-builds esbuild

承認した依存はこの設定が書かれ、そのままビルドまで走ります。

allowBuilds:
  esbuild: true

エラーの再現手順

ホスト環境を汚さないよう、公式のポータブル配布を一時ディレクトリで使い、後で削除しました。

$ ./pnpm/pnpm.exe --version
12.4.2

ビルドスクリプト付きの依存が1つあれば再現できます。postinstall でファイルを1つ書き出すローカル tarball で十分です。

{
  "name": "dummy-build",
  "version": "1.0.0",
  "scripts": {
    "postinstall": "node -e \"require('fs').writeFileSync('BUILT.txt','built by postinstall')\""
  }
}

$ tar -czf dummy-build-1.0.0.tgz -C dummy package
$ cd app
$ ../pnpm/pnpm.exe install
Error: ERR_PNPM_IGNORED_BUILDS

  × installing dependencies
  ╰─▶ Ignored build scripts: dummy-build@file:../dummy-build-1.0.0.tgz
  help: Run "pnpm approve-builds" to pick which dependencies should be allowed
        to run scripts.

exit code は 1 です。レジストリの esbuild でも Ignored build scripts: esbuild@0.25.9 と出ます。

このとき pnpm は承認待ちの一覧を pnpm-workspace.yaml に書き出します。

allowBuilds:
  dummy-build@file:../dummy-build-1.0.0.tgz: set this to true or false

値が set this to true or false という文字列なので、そのまま true に書き換えれば承認できます。一覧は pnpm ignored-builds でも確認できますよ。

$ pnpm ignored-builds
Automatically ignored builds during installation:
  dummy-build@file:../dummy-build-1.0.0.tgz
hint: To allow the execution of build scripts for a package, add its name to "allowBuilds" and set to "true", then run "pnpm rebuild".

なぜ install ごと落ちるのか

止める仕組みは pnpm 10 からありますが、v10 は警告だけで install を成功させていました。

v11 で strictDepBuilds の既定が true になり、未審査のスクリプトが1つでもあると終了コードが非0になります。

同じプロジェクトを v10.34.5 と v12.4.2 で install して比べました（どちらも package.json に v10 時代の pnpm.onlyBuiltDependencies を書いた状態）。

.../esbuild@0.25.9/node_modules/esbuild postinstall$ node install.js
.../esbuild@0.25.9/node_modules/esbuild postinstall: Done

Done in 1s using pnpm v10.34.5

同じディレクトリで v12.4.2 を走らせます。

[WARN] The "pnpm" field in package.json is no longer read by pnpm. The following keys were ignored: "pnpm.onlyBuiltDependencies". See https://pnpm.io/settings for the new home of each setting.

Error: ERR_PNPM_IGNORED_BUILDS

  × installing dependencies
  ╰─▶ Ignored build scripts: esbuild@0.25.9

警告と install の失敗が同時に起きます。警告は流れて消えるので、原因が設定だと気づきにくいのが厄介な点です。

pnpm 11.0 のリリースノートにも、移行時は allowBuilds に寄せるよう明記されています。

直し方

pnpm approve-builds で承認する

対話プロンプトから選ぶのが一番素直です。CI ではパッケージ名を位置引数で渡し、拒否は名前の前に ! を付けます。

$ pnpm approve-builds esbuild
✓ Lockfile passes supply-chain policies (verified 1s ago)
Already up to date
.../esbuild@0.25.9/node_modules/esbuild postinstall$ node install.js
.../esbuild@0.25.9/node_modules/esbuild postinstall: Done

allowBuilds の更新と pnpm rebuild 相当を1コマンドでやってくれます。承認待ちが無くても指定した可否は保存されます（v12.4.0 以降）。

allowBuilds を手で書く

設定ファイルは pnpm-workspace.yaml です。v11 以降 .npmrc は認証とレジストリ専用なので効きません。

allowBuilds:
  esbuild: true
  core-js: false
  # バージョンを絞りたいときは範囲指定もできる
  nx@21.6.4 || 21.6.5: true

レジストリの依存ならパッケージ名だけで承認できます。false は拒否の明示なので、後から見返しても意図が残るのがいいですね。

詳細は公式の allowBuilds リファレンスにまとまっています。

git・tarball 依存は名前だけでは通らない

ここが一番ハマりました。file: や git+https: の依存は、名前だけでは成果物を特定できず承認されません。

# これでは通らない
allowBuilds:
  dummy-build: true

# 解決済みパスなら通る
allowBuilds:
  "dummy-build@file:../dummy-build-1.0.0.tgz": true

パスで指定すると postinstall が走り、書き出したファイルも確認できました。git 依存ならリポジトリURL指定（v11.11.0 以降）が便利です。

allowBuilds:
  "foo@git+https://github.com/org/foo.git": true

拒否（false）は名前だけでも効きます。承認だけが成果物の特定を要求します。

全部許可する逃げ道はある

dangerouslyAllowAllBuilds: true を書けば承認を丸ごとスキップできます。ただし推移的依存も含めて全部実行するので、乗っ取られたときの被害も受けます。

恒久的に使う設定ではなく、切り分けの一時手段ですね。

移行で一緒にハマるポイント

pnpm-workspace.yaml に残った旧設定は黙って無視される

onlyBuiltDependencies を pnpm-workspace.yaml に置いたまま v12 で install したところ、警告は一切出ず、そのまま ERR_PNPM_IGNORED_BUILDS で落ちました。「効いているはず」と思い込みやすい場所です。

この旧設定は pnpm 11.23.0 以降の allowBuilds 書き込み時に掃除されるので、素直に pnpm approve-builds を通すのが安全です。

綴りミスは pnpm 12 でエラーになる

allowBuilds を allowBuild と間違えた場合です。バージョンを pin していないと警告だけで進みます。

[WARN] The following settings in pnpm-workspace.yaml are not recognized by this version of pnpm and were ignored: "allowBuild" (did you mean "allowBuilds"?).

packageManager で pin しているとエラーになります。

Error: ERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGS

  × The following settings in pnpm-workspace.yaml are not recognized by this
  │ version of pnpm: "allowBuild" (did you mean "allowBuilds"?).

pin が無い環境で警告を見逃すと、設定が効かないまま CI だけ通ってしまうので注意してください。

公開直後のバージョンは既定で解決されない

v11 から minimumReleaseAge の既定が 1440（1日）になり、公開24時間未満の版は解決から外れます。

公開直後の版を指名して追加すると、pnpm が除外リストを自動で書き足して通しました。

$ pnpm add @types/node@26.6.0
Added 1 entry to minimumReleaseAgeExclude in pnpm-workspace.yaml (set minimumReleaseAgeStrict to true to gate these updates with a prompt):
  @types/node@26.6.0

つまり pnpm-workspace.yaml がコマンド実行で書き換わります。意図しない差分が出たらこの設定を疑ってください。

供給網攻撃への対策なので、minimumReleaseAge: 0 での無効化は最後の手段ですね。

つまずきポイント

• 設定が効いて見える。 package.json の pnpm も pnpm-workspace.yaml の onlyBuiltDependencies も、無視されるだけでエラーになりません。動かないときは置き場所を疑ってください。
• 対話できない場所で止まる。 CI では位置引数を渡すか allowBuilds を先にコミットします。TTY が無いと削除確認で止まるので、環境変数 CI を立てます。
• tarball の承認キーはパス込み。 名前だけでは承認されないので、エラーに出る解決済みパスをそのままキーにします。
• ロックファイルは再解決されない。 承認後の install では依存の解決はやり直されません。postinstall を走らせたいだけなら pnpm rebuild で足ります。

【広告】【Value AI Writer byGMO】高品質なSEO記事をAIで自動生成。

実測メモ: 承認した依存の postinstall が書き出したファイルは、node_modules の直下ではなく仮想ストア側（node_modules/.pnpm/dummy-build@file+..+dummy-build-1.0.0.tgz/node_modules/dummy-build/BUILT.txt）にできました。トップレベルからはシンボリックリンク越しに見えるので、依存のビルド成果物を直接読みに行くスクリプトを書くときは注意してください。承認したあとに install を流し直すと ✓ Lockfile passes supply-chain policies の行が出て、minimumReleaseAge の判定が改めて走ります。

まとめ

v10 以前の設定は、v11 以降では次のように読み替えます。

書き換えは codemod で機械的にできます。pnpx codemod run pnpm-v10-to-v11 が設定の移動と allowBuilds への統合までやります。

手で直すなら pnpm approve-builds で pnpm-workspace.yaml を確定させ、差分をレビューするのが速いですね。承認が増えたぶん実行されるコードも増えるので、コミット前に一覧を確認しておきましょう。

検証環境

上記の環境で実行して確認した結果です。環境が違えば挙動は変わる場合があります。

参考

本文の記述は以下の一次情報を確認して書いています。実行結果はすべて手元で再現したものです。

• pnpm 公式 — pnpm 11.0 リリースノート（allowBuilds への置き換え、strictDepBuilds の既定変更）
• pnpm 公式 — 設定リファレンス: allowBuilds / strictDepBuilds / dangerouslyAllowAllBuilds
• pnpm 公式 — 設定リファレンス: minimumReleaseAge（v11 で既定が 1440 分に）
• pnpm 公式 — pnpm approve-builds（位置引数と --all、! による拒否）
• pnpm 公式 — pnpm ignored-builds（未承認のビルドスクリプト一覧）
• pnpm 公式 — Migrating from v10（codemod と手動対応の対応表）
• pnpm 公式 — pnpm 12.0 リリースノート（未認識の設定キーをエラーにする変更）
• GitHub — pnpm 11 リリースディスカッション

あわせて読みたい

• 【Node.js】ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX の直し方
• 【Node.js】Node 26 完全ガイド2026 — Temporal API と Iterator.concat
• 【Vite】Vite 8 移行ガイド2026 — Rolldown 統合で壊れる設定
• 【Biome】ESLint + Prettier から Biome v2 への移行ガイド2026

【広告】このサイトはConoHa WINGで運営しています。安定した高速サーバーで快適にブログを書けています。いつもありがとう！！