Lesstep
GitHub Actions・pnpm・2026年11月5日に確認

GitHub Actions の ERR_PNPM_OUTDATED_LOCKFILE：「Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date」と、それを起こす Dependabot のプルリク

CI の環境では、ロックファイルがあれば pnpm install は --frozen-lockfile として動きます。pnpm-lock.yaml を書かず、ロックファイルが package.json と合わなければ失敗します（pnpm の install の説明）。GitHub Actions は CI を設定するので、package.json と一緒に更新されなかったロックファイルは、インストールでジョブを止めます。直し方はほとんどの場合、確認を切ることでなく、ロックファイルを更新してコミットすることです。2026年10月からは、ワークスペースのパッケージの package.json だけを変え、ルートのロックファイルを変えない Dependabot のプルリクが、この失敗の大きな割合を占めています。

見え方

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>/package.json

Note that in CI environments this setting is true by default. If you still need to run install in such cases, use "pnpm install --no-frozen-lockfile"

  Failure reason:
  specifiers in the lockfile don't match specifiers in package.json:
* 2 dependencies are mismatched:
  - @xiboplayer/proxy (lockfile: 0.7.21, manifest: 0.7.22)
  - @xiboplayer/pwa (lockfile: 0.7.21, manifest: 0.7.22)

これは xiboplayer-electron #116 からで、タグを付けたリリースがワークスペースの2つのパッケージの版を上げ、ロックファイルを上げていませんでした（「CI の環境ではこの設定が既定で true。それでもインストールするなら --no-frozen-lockfile」「ロックファイルの指定が package.json の指定と合わない」）。pnpm 12 は同じ理由を枠で囲んだ形（「× installing dependencies」のあとに「Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with package.json」）で出し、in importers["."] のようにワークスペースのどのプロジェクトかも出します。既定で pnpm install まで走る pnpm/setup を使っていると、エラーはセットアップのステップ自体に出ます。

Failure reason の読み方

原因と直し方

ロックファイルを更新せずに変えた package.json

誰かが package.json を手で直したか、リリースのスクリプトが版を上げ、pnpm-lock.yaml を作り直していません。CI と同じ版の pnpm で pnpm install を流し、ロックファイルをコミットします。リリースのスクリプトなら、版を上げたあとに pnpm install --lockfile-only を流し、2つのファイルを一緒にコミットします。

ワークスペースのパッケージへの Dependabot のセキュリティ更新

pnpm のワークスペースでは、apps/ や packages/ の下のパッケージへの Dependabot のセキュリティ更新が、そのパッケージの package.json だけを変え、ルートの pnpm-lock.yaml をそのままにすることがあります。するとプルリクのジョブはすべて ERR_PNPM_OUTDATED_LOCKFILE で落ちます。これは未解決の不具合です（dependabot-core #16680）。pnpm 9.15.9 で報告され、2026年10月28日と31日（2回目は pnpm 12 と directory: "/"）、11月3日（pnpm 12.11.2 での最小の再現）に確かめられています。packages/* の下の版の更新で同じことが起きたプロジェクトもあります（ExaDev/trilean #71）。

pnpm-workspace.yaml の frozenLockfile

pnpm-workspace.yaml（か .npmrc）に frozenLockfile: true があると、Dependabot はロックファイルをまったく更新できません。更新の処理は pnpm install --lockfile-only を流し、pnpm は環境変数よりファイルの設定を優先し（上書きできるのはコマンドラインのフラグだけ、と報告にあります）、ジョブの更新はすべて dependency_file_not_resolvable で失敗して、セキュリティ更新のプルリクが1本も開きません（dependabot-core #16744・Renovate でも同じ）。CI はもともと既定で frozen なので、ファイルからこの設定を外すか、代わりにワークフローのインストールのステップで --frozen-lockfile を付けます。

ワークスペースの package.json が無い Docker の段

一部のファイルだけを写してから pnpm install --frozen-lockfile を流すマルチステージの Dockerfile は、ロックファイルにあるワークスペースのプロジェクトの package.json を写していないと落ちます（caprover-app-template #12：1段目は client/package.json を写し、2段目は写していなかった）。インストールの前に pnpm-workspace.yaml・pnpm-lock.yaml・ワークスペースのすべての package.json を写すか、pnpm fetch でロックファイルだけから取ってきてから pnpm install --offline でインストールします。イメージの中の pnpm の版も決めておきます。

やらないこと

CI と手元で同じ pnpm に

package.json の packageManager で pnpm を決めます（例："packageManager": "pnpm@12.16.1"）。pnpm/action-setup も pnpm/setup も、version の入力が無ければこれを読み、Vercel のビルドのログにも出ます（「Detected `pnpm-lock.yaml` version 9 generated by pnpm@12.x from package.json#packageManager」）。CI だけでエラーが出るなら、ロックファイルを作り直す前に、ジョブと手元の pnpm --version を比べます。

見分け方

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、インストールで落ちた Dependabot のプルリクがすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

JetBrains Marketplace で入れる

GitHub・GitHub Actions・Dependabot は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標、Docker は Docker, Inc. の商標、Vercel は Vercel Inc. の商標です。このページはそのいずれとも提携しておらず、承認も受けていません。

ほかに：Unable to locate executable file: pnpm · Dependencies lock file is not found · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English