pnpm 12.0 リリース

pnpm 12が安定版になりました。これはRustによるpnpmの書き直しであり、意図的にマイグレーションではありません。コマンド、フラグ、設定、ロックファイル形式はすべてpnpm 11から引き継がれており、ドキュメントには両方のバージョンが記載されています。本当に挙動が異なる点の短いリストは「pnpm 12での変更点」にあります。この記事では、pnpm 11にはなかったpnpm 12の新機能について説明します。npmでlatestをインストールすると、依然としてpnpm 11のラインを指すため、pnpm 12はnext-12タグからインストールされます。 pnpm self-update next-12 Node.jsなしでのインストール方法など、他の方法については「pnpm 12のインストール」を参照してください。Homebrew、winget、Scoop、Chocolateyはまだ提供していません。 破壊的な変更 Git依存関係はアイデンティティになります GitHub、GitLab、Bitbucketのリポジトリでは、指定子はトランスポートを選択するのではなく、リポジトリを名前で指定するようになりました。github:owner/repo、owner/repo、git+https://…、git+ssh://git@…はすべてホストの正規HTTPS URLを通じて解決され、ロックファイルはそれらのホストのSSH URLを記録しません。SSH経由でプライベートホストリポジトリに到達するには、GitのURL書き換えでマシンを設定してください: git config --global url."git@github.com:".insteadOf https://github.com/ pnpmはgitにシェルアウトするため、書き換えはすべてのgit操作に適用されます。認識されないホストは、SSHを含め、その正確なURLを保持し、埋め込み認証情報を持つURLはそのまま保持され、ホストに解決されることはありません。詳細は「Git依存関係の解決方法」を参照してください。 pnpm-workspace.yamlの認識されない設定が報告されるようになります pnpmが認識しない設定は、以前はサイレントに無視されていました。例えば、最小リリース年齢のスペルミスによって設定されていたポリシーが適用されず、何も通知されませんでした。現在は報告され、キーがタイポのように見える場合は、最も近い実際のキー名が提案されます。プロジェクトが実行中のpnpmを満たすpnpmバージョンをピン留めしている場合、コマンドはERR_PNPM_UNRECOGNIZED_WORKSPACE_SETTINGSで失敗します。ピンが尊重されると、設定は別のpnpmバージョン向けであったはずなので、無視するキーではなく修正すべき間違いとなります。それ以外の場所では警告となるため、まだクリーンアップされていないプロジェクトは引き続き動作します。pnpm configサブコマンドはこれらで失敗しないため、壊れたファイルを検査して修復できます。 循環依存グラフのロックファイル ピア解決中に依存関係のサイクルが正規に壊れるようになりました。各サイクルのメンバーはパッケージIDで順序付けられ、サイクルを閉じるエッジは、インストールがサイクルにどこから入っても、常に同じ場所でカットされます。したがって、ロックファイルは依存関係グラフの純粋な関数になります。インポーターの順序変更、依存関係の順序変更、繰り返しインストールはすべて、以前はできなかったバイト単位で同一のロックファイルを生成します（#13846、#13865）。大きなサイクルが多いワークスペースでは、ピア解決が2〜3倍高速になり、メモリ使用量が約25%減少し、ロックファイルが大幅に小さくなります。既存のロックファイルは引き続き機能します。--frozen-lockfileはそれらを変更せずに消費し、解決をスキップするインストールはそれらをそのままにします。実際に再解決する最初のインストールは、サイクリックパッケージのウォーク順序依存のピアバリアントを一度再キーイングします。詳細は「ピアの解決方法」を参照してください。 packageImportMethod: auto はLinuxでハードリンクを優先します reflinkは新しいinodeをマテリアライズし、ファイルシステムのメタデータツリー内でエクステントのブックキーピングをコピーしますが、ハードリンクは1つのディレクトリエントリです。btrfsでは、インストールがウォームストアからnode_modulesをマテリアライズする時間を約半分にします。そのため、Linuxではautoはまずハードリンクを試みます。ext4は変更されません（クローニングはサポートされていなかったため、autoはすでにハードリンクしていました）。macOSはクローンファーストを維持しており、APFSのclonefileはプラットフォームの低コストプリミティブです。Linuxでは、クローニングは最初のステップではなく2番目のステップになるため、ハードリンクを拒否するストアでもクローンを取得できます。packageImportMethod: clone は依然としてそれを直接要求します。 engineStrict はサブツリーではなくエッジに従います engineStrictの下で、互換性のないパッケージがインストール可能なパッケージの通常の依存関係エッジを通じて到達した場合、たとえそのサブツリー全体がoptionalDependenciesエントリにぶら下がっていても、インストールは失敗するようになりました。pnpm 11ではパッケージをインストールし、インストールチェックの警告を発しました。オプションエッジのみを通じて到達可能なパッケージ、またはそれ自体がスキップされたパッケージは、両方のバージョンで引き続きスキップされます（#13286）。 新機能 これらのすべてがpnpm 12限定ではありません。レジストリリビジョン、リモートサイドエフェクトキャッシュ、audit.ignorePrune、バッチステージ承認、pnpm initのlatest-tagピンはpnpm 11.25でも提供されます。残りはv12のみです。なぜなら、それらはRustリライトに属するからです。 プロジェクト認識型のグローバルbin グローバルにインストールされたnode、deno、またはbunは、常にグローバルにインストールされたものを実行するのではなく、現在のプロジェクトがピン留めするバージョンに従います。シェルフックやuseスタイルのコマンドはありません。新しいglobalShims設定は、どのグローバルにインストールされたパッケージがそのようなシムを持つかを選択します。デフォルトは { node: true, deno: true, bun: true } で、キーごとにマージされるため、globalShims: { typescript: true } は残りを再指定せずにシムを追加します。安定したNode.jsリリースは、Node.jsリリースチームの署名に対して認証され、尋ねることなく切り替わります。それ以外のすべて（Deno、Bun、Node.jsのプレリリース、有効にした通常のパッケージbin）は、プロジェクトごとおよび候補ごとに「このプロジェクトを信頼しますか？」と一度尋ね、マシンローカルに回答を記憶します。PNPM_SHIM_BYPASS=1 は、1回の呼び出しでこの機能をバイパスします。詳細は「プロジェクト認識型のグローバルbin」を参照してください。 pnpmは他のパッケージマネージャーをインストールします pnpmは現在、npm、Yarn Classic、Yarn Berry、Yarn 6 (yarnpkg/zpm)、およびBunをプロビジョニングします。それぞれが信頼できるパッケージマネージャーレジストリを通じて取得され、npmで公開されたものは実行前にその正確なバージョンに対するnpmの署名に対して検証されます。3つのことがこれを使用します。gitホストの依存関係は、要求されたパッケージマネージャーで準備されるため、Yarnでビルドされたリポジトリは、マシンにpnpmしかなくてもインストールできます。pnxは単一コマンドで実行します — pnx yarn@4 install、pnx npm@11 ci、pnx node@22。そしてpnpm shim add yarnは、現在のプロジェクトがピン留めするものを実行するyarnをリンクします。パッケージマネージャーの名前を付けることは、その名前を共有するnpmパッケージではなく、ツールを意味します。pnpm add -g yarn@4 はYarn Berryをインストールし、プロジェクト内ではpnpm add yarn@4 は "packageManager": "yarn@4.18.0"（Corepackが読み取るもの）を記録しますが、他のすべてのパッケージマネージャーはdevEngines.packageManagerに記録されます。パッケージを見つける指定子は、依然として名前でパッケージをインストールします（pnpm add yarn@npm:yarn@1.22.22）。詳細は「その他のパッケージマネージャー」を参照してください。 レジストリリビジョン レジストリは、バージョン番号を変更したり、正規のname@version URLが常に提供してきたバイトを書き換えたりすることなく、既に公開されたバージョンの代替アーティファクト（脆弱性がパッチアウトされたリビルド）を提供できます。pnpmは各アーティファクトをリビジョンと呼び、その完全なSHA-512ダイジェストでアドレス指定し、ロックファイルに1行追加して記録します: pnpm-lock.yaml packages: lodash@4.17.21: resolution: integrity: sha512-<replacement-digest> revision: 1 リビジョンがないエントリはリビジョン0、つまりオリジナルです。pnpmがこれまで書き込んだすべてエントリの意味するところはこれであり、リプレイスメントを採用していないロックファイルは今日のそれとバイト単位で同一です。依存関係またはオーバーライドは、<version>+rNとしてリビジョンを明示的にピン留めできます。pnpm update --patches は、バージョンを1つ変更することなくロックされたアーティファクトをリフレッシュします。pnprはホストするパッケージのリビジョンを提供し、それらを宣伝するアップストリームレジストリのプロキシを行います。詳細は「レジストリリビジョン」を参照してください。 pnpm init は最新のpnpmをピン留めします pnpm init は、コマンドを実行したバージョンではなく、最新リリースされたpnpmをピン留めするため、古いpnpmでスキャフォールドされたプロジェクトは、それ自体のピンを通じてその古さを継承しなくなります（#7490）。最新のルックアップが回答できない場合（ネットワークなし、レジストリが遅い、オフライン、またはlatestがminimumReleaseAgeまたはtrustPolicyによって拒否された場合）、実行中のバージョンは以前と同様にピン留めされます。ルックアップはコマンドを失敗させたりハングさせたりすることはありません。 ステージングされた公開のためのバッチ承認 pnpm stage approve は複数のステージングされたパッケージを一度に承認します。