pnpm 11 リリース候補版：ESM配布、サプライチェーンのデフォルト設定、新ストア形式
pnpm 11 Release Candidateが公開され、SQLite搭載のストアインデックスやセキュリティ強化defaults、Node.js v22以降の必須化などにより、開発環境の基盤が刷新された。
キーポイント
ストレージインフラのSQLite化
パッケージストアのインデックスにSQLiteを採用し、読み込み速度と管理効率を大幅に向上させた。
セキュリティと設定の統合強化
サプライチェーン攻撃への対策としてデフォルト設定を厳格化し、ビルドスクリプトの統合設定を導入した。
Node.js v22必須化とグローバルインストールの分離
実行環境としてNode.js v22以降を必須とし、グローバルインストールをデフォルトで分離する仕様に変更した。
ESM配布と新コマンドの追加
モダンなJavaScript標準であるESM形式での配布に対応し、ユーザビリティを向上する新コマンドを追加した。
影響分析・編集コメントを表示
影響分析
このアップデートは、Node.jsエコシステムにおけるパッケージ管理のセキュリティ基準を一段階引き上げ、サプライチェーン攻撃への防御力を強化する。Node.js v22の必須化とESM配布の推進は、モダンなJavaScript開発環境への移行を加速させ、AIインフラ構築時の依存関係管理の信頼性を高める。
編集コメント
開発者ツールにおけるサプライチェーンセキュリティの標準化は、AIモデル構築時の依存関係管理にも直結する重要なステップである。Node.js v22必須化は環境構築の統一を促すため、チーム開発での採用検討が推奨される。
高速でディスク効率に優れた JavaScript パッケージマネージャーである pnpm は、pnpm 11 RC をリリースしました。このバージョンでは、パフォーマンス、サプライチェーンの安全性、そしてより小型で厳格な設定インターフェースにわたる大規模な改訂が施されています。
pnpm 11 RC では、SQLite をバックエンドとする新しいストアインデックス（store index）の導入、デフォルトで有効になるサプライチェーン保護機能、グローバル仮想ストア（global virtual store）による分離されたグローバルインストール、統合された allowBuilds 設定、そして pnpm ci、pnpm sbom、pnpm clean、pnpm peers check、pnpm runtime set という一連の新コマンドに加えて、短縮エイリアスである pn と pnx が追加されています。
目玉変更の一つは、pnpm が純粋な ESM（ECMAScript Module）として配布され、Node.js v22 以降を必要とするようになった点です。Node.js 18、19、20、21 のサポートは完全に削除されました。互換性マトリックスは更新されたインストールドキュメントに記載されています。
セキュリティデフォルトが強化され、minimumReleaseAge 設定のデフォルト値が 1 日になりました。これは、公開されたばかりのバージョンは 24 時間以内に解決されないことを意味します。また、blockExoticSubdeps のデフォルト値も true に設定されました。これは npm エコシステムで過去数ヶ月間にわたって発生した大規模なサプライチェーンインシデントを受けての措置であり、Hacker News 上でも議論を巻き起こしました。そこではコメント投稿者たちが、猶予期間が検出に実際にどの程度役立つのかについて論争を繰り広げました。
ビルドスクリプトの設定が統合されました。onlyBuiltDependencies、onlyBuiltDependenciesFile、neverBuiltDependencies、ignoredBuiltDependencies、ignoreDepScripts は削除され、単一の allowBuilds オプションに統一されました。また、strictDepBuilds のデフォルト値は true になりました。pnpm はさらに、package.json の "pnpm" フィールドおよび npm_config_ 環境変数からの設定読み取りを停止しました。グローバル設定ファイルは YAML 形式に移行し、allowNonAppliedPatches、ignorePatchFailures、pnpm server、useNodeVersion は削除されました。
グローバルインストールが適切に分離され、各 pnpm add -g パッケージは独自のディレクトリ、package.json、node_modules、ロックファイル（lockfile）を受け取ります。また、グローバル仮想ストアは pnpm dlx およびグローバルパッケージに対してデフォルトで有効化されていますが、通常のプロジェクトではオプトイン方式のままです。パフォーマンス向上の取り組みとしては、HTTP 通信に Happy Eyeballs を搭載した undici への移行、ステージングディレクトリをスキップして直接ストアへ書き込む処理、事前割り当てされた tarball ダウンロード、NDJSON 形式のメタデータキャッシュが含まれます。
開発者は今日、以下のコマンドでこのリリースを試すことができます：
pnpm self-update next-11
マイグレーションガイドは pnpm 11.x ドキュメントおよび v11 追跡ディスカッションに記載されています。
Hacker News 上では、最近のセキュリティ脆弱性に関するスレッドで、あるコメント投稿者が pnpm を npm よりも強く推奨し、「PNPM 10.x はこれらの攻撃ベクトル（attack vectors）の多くをシャットダウンした」「NPM は本番環境の CLI 利用にはセキュリティ上不十分すぎる」と述べていました。ただし、他のユーザーからは反論があり、「NPM は決して不十分すぎるセキュリティではなかったし、今日でもそうではない」と主張する声が上がりました。
minimumReleaseAge のデフォルト値は特に注目の的となっており、「依存関係のクールダウン（dependency cooldowns）」とも呼ばれています。Hacker News 上の依存関係のクールダウンに関するスレッドでは、このトピックを巡ってさらなる議論が交わされ、あるコメント投稿者が次のように指摘しました：
冷却期間（クールダウン）の恩恵を受ける人々は、そもそもアップデートをレビューしていなかった。冷却期間がなければ、彼らは単なるマルウェア被害者の一人に過ぎないだろう。
一方、他のコメント投稿者は以下のように警告している：
ここに無料の午餐はない。公開の遅延は攻撃を遅らせるだけでなく、重要なセキュリティパッチ（security patches）の適用も遅らせる。一律最適のポリシーなど存在せず、どちらを選んでもリスクを抱えることになる。
npmやYarnと比較して、pnpm 11はデフォルトでnode_modulesを分離し、コンテンツアドレス型ストレージ（content addressable storage）を採用し、ファーストクラスのモノレポ（monorepo）サポートを提供するという長年の優位性を維持しつつ、pnpm sbomによるSBOM（Software Bill of Materials）生成やビルドスクリプトの厳格な処理によりセキュリティ面でのリードを拡大している。これらはYarnがまだ追いついていない領域である。
pnpmは、コンテンツアドレス型ストア（content addressable store）とシンクリンクされたnode_modulesにより、高速なインストールと効率的なディスク使用で知られるオープンソースのJavaScriptパッケージマネージャーである。フロントエンドおよびバックエンドのエコシステム全体で広く使用されており、npm、Yarn、Bunと直接競争している。
著者について
Daniel Curtis
Daniel Curtisは、英国バーミンガムに拠点を置くソフトウェアコンサルティング会社Griffiths WaiteのUI開発マネージャーである。彼はTypeScriptをスタック全体に活用した革新的なエンタープライズソリューションの提供に重点を置き、フロントエンドエンジニアリングの取り組みをリードしている。DanielはモダンなWebアーキテクチャ、開発者体験（Developer Experience）、そしてソフトウェア納品の支援や製品内の実際の顧客課題解決にAIを活用することに情熱を注いでいる。
詳細を表示 表示を閉じる
原文を表示
pnpm, the fast and disk efficient JavaScript package manager has released pnpm 11 RC, shipping a major rework that spans performance, supply chain safety, and a smaller, stricter configuration surface.
pnpm 11 RC introduces a new SQLite-backed store index, on by default supply chain protections, isolated global installs via the global virtual store, a unified allowBuilds setting, and a set of new commands including pnpm ci, pnpm sbom, pnpm clean, pnpm peers check, and pnpm runtime set, along with short pn and pnx aliases.
One of the headline changes is that pnpm is now distributed as pure ESM and requires Node.js v22 or later, with support for Node.js 18, 19, 20, and 21 dropped entirely. A compatibility matrix lives in the updated installation docs.
Security defaults are have been tightened, the minimumReleaseAge setting now defaults to 1 day, meaning newly published versions are not resolved for 24 hours, and blockExoticSubdeps defaults to true. This follows months of high profile supply chain incidents in the npm ecosystem, and drew discussion on Hacker News where commenters debated whether a grace period would meaningfully help detection.
Build script settings have been consolidated, onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies, and ignoreDepScripts have been removed in favour of a single allowBuilds option, and strictDepBuilds is now true by default. pnpm also stops reading configuration from the "pnpm" field of package.json and from npm_config_ environment variables, the global configuration file has moved to YAML, and allowNonAppliedPatches, ignorePatchFailures, pnpm server, and useNodeVersion are gone.
Global installs are now properly isolated, each pnpm add -g package receiving its own directory, package.json, node_modules, and lockfile, and the global virtual store is enabled by default for pnpm dlx and global packages, although it remains opt in for regular projects. Performance work includes a move to undici with Happy Eyeballs for HTTP, direct to store writes that skip the staging directory, pre-allocated tarball downloads, and an NDJSON metadata cache.
Developers can try the release today with:
pnpm self-update next-11
Migration guidance lives in the pnpm 11.x docs and the v11 tracking discussion.
On Hacker News, one commenter recommended pnpm over npm outright on a thread about recent security vulnerabilities, stating that "PNPM 10.x shutdown a lot of these attack vectors" and "NPM is too insecure for production CLI usage", though others pushed back, arguing that "NPM was never too insecure and remains not too insecure today".
The minimumReleaseAge default has been a particular focal point, also being referred to as 'dependency cooldowns'. A Hacker News thread on dependency cooldowns drew further debate around the topic, with one commenter noting that:
The people who will benefit from a cooldown weren’t reviewing updates anyway. Without the cooldown they would just be one more malware victim
While other commenters warned:
There's no free lunch here. Delays in publishing not only slow down attacks, they also slow down critical security patches. There's no one-size-fits-all policy here, you're at risk either way.
Compared to npm and Yarn, pnpm 11 retains its long standing advantages, isolated node_modules by default, content addressable storage, and first class monorepo support, while extending its lead on security with SBOM generation via pnpm sbom and stricter build script handling, areas where Yarn still lacks parity.
pnpm is an open source JavaScript package manager known for fast installs and efficient disk usage via a content addressable store and symlinked node_modules. It is widely used across frontend and backend ecosystems, and competes directly with npm, Yarn, and Bun.
About the Author
Daniel Curtis
Daniel Curtis is a UI Development Manager at Griffiths Waite, a software consultancy based in Birmingham, UK. He leads front-end engineering efforts with a strong focus on delivering innovative enterprise solutions using TypeScript across the stack. Daniel is passionate about modern web architecture, developer experience, and the use of AI to both support software delivery and solve real customer problems within products.
Show moreShow less
関連記事
パッケージマネージャーは冷静になる必要がある
著者がLiteLLMのサプライチェーン攻撃を契機に、依存関係の更新を数日間待つ「クールダウン」の実践を再検討し、パッケージマネージャーのセキュリティ対策の重要性を主張している。
TanStack npm サプライチェーン攻撃へのOpenAIの対応
OpenAIは、TanStackを介したnpmサプライチェーン攻撃「Mini Shai-Hulud」に対し、システムと署名証明書の保護策を講じたと発表しました。同社は、macOSユーザーが2026年6月12日までにアプリを更新するよう要請し、ソフトウェアサプライチェーンの脅威に対する防御強化を図っています。
シャドー IT からシャドー AI へ：AI-BOM の登場
企業サプライチェーンのセキュリティ強化において、従来のソフトウェア部品表（SBOM）では不十分となったため、AI アプリケーションやエージェントを含む全構成要素を把握する「AI-BOM」が新たな対策として導入される。