pnpm 11 リリース候補版：ESM配布、サプライチェーンのデフォルト設定、新ストア形式

高速でディスク効率に優れた 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 11 リリース候補版：ESM配布、サプライチェーンのデフォルト設定、新ストア形式

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

調べる

選ぶ

サイト