JavaScript パッケージマネージャーの比較: Npm vs Yarn vs Pnpm

パッケージ マネージャーの領域には、次の 3 つの主要なプレーヤーがあります。

• npm

• Yarn

• ハイパフォーマンス npm (pnpm)

実際には、すべてのパッケージ マネージャーに基本的に同様の機能が実装されているため、機能以外の要件に基づいてどれを使用するかを決定する可能性が高くなります。 パッケージ マネージャー、インストール速度、ストレージの消費、実用性など。

もちろん、各パッケージ マネージャーの使用方法は異なりますが、基本的にはすべてのパッケージ マネージャーに一貫した概念があります。上記のパッケージ マネージャーはすべて、次のコマンドを実行できます。

• データの読み取りと書き込み
• すべての依存関係のバッチ インストールまたは更新 依存関係
• の追加、更新、削除
スクリプトの
• 実行 パッケージの
• 公開

ただし、それにもかかわらず、パッケージ マネージャーは内部的には異なります。従来、 npmとYarn依存関係をフラットな node_modules フォルダーにインストールしていました。 （こちらの注文に注意してください。 yarn最初にタイル張り、 npm以前に再帰的でした）。しかし、タイル張りは一連の安全上の問題を引き起こす可能性もあります。

• 依存構造の不確実性。

• 平坦化アルゴリズム自体は非常に複雑で時間がかかります。

• 依存関係

• を

より効率的に保存するために、 pnpm node_modulesフォルダーにいくつかの新しい概念が導入されました。 Yarn Berryさらに、 node_modulesの (PnP) モードを完全に放棄することでさらに進んでいます (これについては別の記事で詳しく説明します)。

JavaScript パッケージの簡単な歴史

最も早くリリースされたパッケージ マネージャーは、2010 年 1 月にリリースされたnpmでした。これは、今日のパッケージ マネージャーがどのように機能するかの中核となる原則を確立しました。しかし、 npm 10 年以上存在しているのに、なぜ他の選択肢があるのでしょうか?これが当てはまる主な理由は次のとおりです。

• node_modulesフォルダー構造には、さまざまな依存関係解決アルゴリズム (ネストおよびタイル、 node_modulesと PnP モード) および
• さまざまな依存関係ホイスティング方法 ( hoisting )
• さまざまなlocking形式 ( yarn自体によって記述されたものなど、さまざまなパフォーマンス)
• ディスク ストレージ パッケージ さまざまなファイルがあります。フォーマット (スペース効率の違い)
• monoreposの保守性と速度に影響を与える、マルチパッケージ プロジェクト (別名workspaces ) のサポートの違い
• 新しいツールとコマンドに対するさまざまなニーズ (プラグインやコミュニティ ツールによる拡張性に対するさまざまなニーズ)
• 構成可能性と柔軟性の違い それでは、詳しく

見ていきましょうnpmの台頭後にこれらの側面がどのように決定されたかの歴史、 Yarn Classicこれらの問題のいくつかをどのように解決したか、 pnpmこれらの概念をどのように拡張したか、 Yarn Classicの後継者としてYarn Berryこれらの伝統的な概念とプロセスをどのように打ち破ったかの歴史です。

Pioneer npm

npmパッケージ マネージャーの元祖です。多くの人々は、 npmが「ノードパッケージマネージャー」の頭字語であると誤って信じていますが、そうではありません。

そのリリースは、以前にプロジェクトの依存関係が手動でダウンロードされ管理されたため、革命を構成しました。 npm 、ファイルやそのメタデータフィールドなどのものを導入し、 node_modules 、カスタムスクリプト、パブリックおよびプライベートパッケージなどに依存関係を保存しました。

2020年にGitHubがnpmを買収したため、 npm原則としてMicrosoftが管理することになりました。執筆時点での最新メジャー バージョンは v8 で、2021 年 10 月にリリースされます。

Innovator Yarn Classic

2016 年 10 月、Facebook は、当時存在していた npm の一貫性に対処するための新しいパッケージ マネージャー (engineering.fb.com/2016/10/11/…) を開発するために Google および他の多くの企業と提携することを発表しました。セキュリティとパフォーマンスの問題。彼らはその代わりの糸を「糸」と名付けました。

Yarnは依然としてnpmの多くの概念とプロセスに基づいて設計および構築されていますが、 Yarnパッケージ マネージャーの分野に大きな影響を与えています。 npmと比較して、 Yarn操作を並列化してインストール プロセスを高速化します。これは、 npmの以前のバージョンの大きな問題点でした。

Yarn読み取りと書き込み、セキュリティとパフォーマンスに関してより高い基準を設定し、多くの概念を発明しました (後にnpmもこのために多くの改良を加えました)。

• monorepoキャッシュをサポートし
、
• オフライン ダウンロード
• ファイル ロック ( Locking )
• のインストールを

。 Yarn v1 でメンテナンス モードに入る2020年。それ以来、v1.x シリーズはレガシーとみなされ、 Yarn Classic名前に変更されました。その後継となる Yarn v2 (Berry) は、現在、より活発な開発ブランチです。

より効率的なpnpm

pnpmのバージョン 1 は、2017 年に Zoltan Kochan によってリリースされました。これはnpmの代替となるため、 npmプロジェクトをお持ちの場合は、すぐにpnpm使用できます。

pnpmが作成された主な理由は、 npmとYarnプロジェクト間で使用される依存関係のストレージ構造の点で非常に冗長であるためです。 Yarn Classic npmよりも速度に優れていますが、 pnpm同じ依存関係解決方法を使用します。npm とnpm Yarn Classic hoisting node_modules

以前の構造を最適化する代わりにホイスティングを使用して、node_modules を平坦化します。pnpm pnpm別の依存関係解決戦略が提案されています。コンテンツアドレス指定されたストレージ構造。このメソッドによって生成されるnode_modulesフォルダーは、実際には、メイン フォルダーにグローバルに保存されている~/.pnpm-store/ディレクトリに依存します。依存関係の各バージョンは、このディレクトリ フォルダーに物理的に一度保存され、単一のソース アドレスを形成して、ディスク領域を大幅に節約します。

node_modules構造は、 symlinksを使用して作成された依存関係の入れ子構造です (フォルダー内の各ファイル/パッケージはハード リンクを通じて保存されます)。公式ドキュメントの次の図は、これを示しています。 (埋められる画像: ソフトリンクとハードリンク)

pnpmの影響は、2021年のレポートで表示されます。コンテンツアドレス型ストレージの革新のため、競合他社は、シンボリックリンクの構造やパッケージの効率的なディスク管理など、 pnpm概念を採用することを検討しています。

Plug'n'Play で車輪を再発明する Yarn (v2、Berry)

Yarn 2 は 2020 年 1 月にリリースされ、オリジナルのYarnへのメジャー アップグレードとして請求されました。 Yarnチームは、これが本質的に新しいコード ベースと新しい原則を備えた新しいパッケージ マネージャーであることをより明確にするために、これをYarn Berryと呼んでいます。

Yarn Berryの主な革新は、node_modules を修復するための戦略としてのプラグ アンド プレイ (PnP) アプローチです。 node_modulesを生成する戦略の代わりに、依存関係ルックアップテーブルを備えたファイル.pnp.cjsを生成します。これにより、ネストされたフォルダー構造ではなく単一のファイルであるため、依存関係のより効率的な処理が可能になります。さらに、各パッケージは.yarn/cache/ではなく zip ファイルの形式でフォルダーに保存され、必要なディスク容量はnode_modulesよりも少なくなります。

これらすべての変更は非常に急速に起こったため、リリース後に多くの論争を引き起こしました。このような壊れた壊れた変更は、PNPの壊れた変更で、メンテナーが既存のパッケージを更新して互換性がある必要があります。新しい PnP アプローチをデフォルトで使用し、 node_modulesに戻すことは当初は簡単ではありませんでした。そのため、多くの有名な開発者がそれを考慮せず、Yarn 2 を公に批判しました。

それ以来、 Yarn Berryチームはその後のリリースで多くの問題に対処してきました。 PnP の非互換性の問題を解決するために、チームはデフォルトの動作モードを簡単に変更する方法を提供しました。 node_modules プラグインを使用すると、従来のnode_modulesアプローチに戻すには、1 行の設定のみが必要になります。

さらに、JavaScript エコシステムは時間の経過とともに PnP のサポートを強化しており、この互換性表からわかるように、いくつかの大規模なプロジェクトがYarn Berry採用し始めています。

Yarn Berryまだ若いですが、すでにパッケージ マネージャー領域に影響を与えています。pnpm pnpm 2020 年後半に PnP アプローチを採用しました。

インストールのワークフロー

パッケージ マネージャーは、まず各開発者のローカル システムおよび CI/CD システムにインストールする必要があります。

npm

npm Node.jsに同梱されているため、追加の手順は必要ありません。オペレーティング システム用の Node.js インストーラーをダウンロードすることに加えて、CLI ツールを使用してソフトウェア バージョンを管理することが一般的になりました。ノードのコンテキストでは、ノードバージョンマネージャー（NVM）またはVoltaは非常に便利なユーティリティになりました。

Yarn Classic と Yarn Berry

Yarn 1 は、 npmパッケージなど、さまざまな方法でインストールできます。 .$ npm i -g yarn

Yarn Classic から Yarn Berry に移行するには、次の方法が推奨されます。

• Yarn Classicを To にインストールまたは更新します

。最新

• バージョン

にアップグレードするには、

• yarn set version berry

  コマンドを使用します

  。

ただし、ここで Yarn Berry をインストールする推奨方法は、Corepack を使用することです。

Corepack は Yarn Berry の開発者によって作成されました。このイニシアチブは当初、Package Manager Manager (pmm) という名前でしたが、LTS v16 で Node に統合されました。

Corepack の助けを借りて、Node はnpmの代替パッケージ マネージャーです。Node にはYarn Classic 、 Yarn Berry 、およびpnpmバイナリが含まれているため、「個別に」インストールする必要はありません。これらの shim を使用すると、ユーザーは最初に明示的にインストールせずに、またノードの配布を台無しにすることなく、Yarn および pnpm コマンドを実行できます。

corepackには、node.js≥v16.9.0でプリインストールされています。ただし、古いノードバージョンの場合、⬇️npm

インストール-g corepackを

、使用する前にcorepackを有効にすることができます。この例では、Yarn Berry v3.1.1 でアクティブ化する方法を示します。

# 最初にオプトインする必要があります
$ コアパックを有効にする
# シムはインストールされていますが、具体的なバージョンをアクティブ化する必要があります
$ corepack [email protected] --activate

pnpm

pnpm npmパッケージとしてインストールできます: $ npm i -g pnpm 。 Corepack を使用して pnpm をインストールすることもできます。

$ corepack prepare [email protected] --activate

プロジェクト構造

このセクションでは、さまざまなパッケージ マネージャーの主な機能が一目でわかります。特定のパッケージマネージャーの構成に関係しているファイルと、インストールステップでどのファイルが生成されるかを簡単に見つけることができます。

すべてのパッケージマネージャーは、すべての重要なメタ情報をProject Manifest Package.jsonファイルに保存します。 さらに、ルートレベルの構成ファイルを使用して、さまざまなプライベートパッケージまたは異なる依存関係解像度構成をセットアップできます。

インストールステップ中、 dependencies node_modulesなどのファイル構造に保存され、 lockingファイルが生成されます。このセクションでは、ワークスペースの設定を考慮していないため、すべての例は、依存関係が保存されている単一の場所のみを示しています。

$ npm installまたは短い$ npm iを使用してnpmは、 package-lock.jsonファイルとnode_modulesフォルダーを生成します

。

ルート レベルのディレクトリに配置できる.npmrcなどの構成可能なファイルもあります。ファイルのlockingの詳細については、次のセクションを参照してください。

。
§── ノードモジュール/
§── .npmrc
package-lock.json
package.json

Yarn

$ yarnを実行すると、 yarn.lockファイルとnode_modulesフォルダーが作成されます。 .yarnrcファイルも構成オプションにすることができ、 Yarn Classic .npmrcファイルもサポートします。あるいは、キャッシュ フォルダー.yarn/cache/と、ローカルの.yarn/releases/に保存されている最新のYarn Classicバージョンを使用することもできます。

。
§── .yarn/
│├├。cache/
│ └── リリース/
│ └─ 糸-1.22.17.cjs
§── ノードモジュール/
§── .yarnrc
§── package.json
└└）lock

Yarn Berry：node_modules

この特別なインストールモードのため、他のパッケージマネージャーよりもYarn Berryプロジェクトでより多くのファイルとフォルダーを扱う必要があります。一部はオプションであり、一部は必須です。

Yarn Berry .npmrcまたは.yarnrcをサポートしなくなりました。 node_modulesフォルダーの生成の従来のワークフローの場合、 node_modulesまたはpnpm構成を使用するにはnodeLinker構成を提供する必要があります（この部分はわかりません）。

＃.yarnrc.yml
nodeLinker:node-modules # または

$ yarnを実行する pnpm は、すべての依存関係をnode_modulesフォルダーにインストールします。 yarn.lockファイルが生成されますが、これはより新しいですが、 Yarn Classicと互換性がありません。さらに、オフラインインストールのために.yarn/cache/フォルダーが生成されます。このフォルダーはオプションであり、プロジェクトで使用されるYarn Berryのバージョンを保存するために使用されます。

。
├├）/ yarn/
│├├。cache/
p
│└│。-YARN-3.1.1.CJS
├├）node_modules/
├··ックス。yarnrc.yml
§── package.json

のロック

ヤーンベリー：PNPが

PNPの厳密なモードであろうとルースモードであろうと、 .pnp.cjsとyarn.lockを使用して$ yarn実行するかどうかは.yarn/cache/および.yarn/unpluggedを生成します。 PNP Strictはデフォルトモードを設定する場合は、次のフォームで有効にする必要があります

。
Nodelinker：PNP
PNPMode：

PNPプロジェクトでは、 releasesフォルダーに加えて、 .yarnフォルダーにはIDEサポートを提供するsdk/フォルダーも含まれている可能性があります。ユースケースに応じて、 .yarnより多くのフォルダーを含めることもできます。

。
├├）/ yarn/
│├├。cache/
p
││└│。。
││·ックス/ sdk/
│└··ックス/プラグがありません
pnp.cjs
pnp.loader.mjs
├··ックス。yarnrc.yml
§── package.json
━──yarn.lock`

pnpm

npmまたはYarn Classicプロジェクトと同じですpnpmにもpackage.jsonファイルが必要です。 $ pnpm i使用して依存関係をインストールすると、 node_modulesフォルダーが作成されますが、その内容はアドレス指定可能なストレージであるため、その構造は完全に異なります。

pnpm独自のロックファイルpnp-lock.ymlも生成します。 オプションの.npmrcファイルを使用して追加の構成を提供できます。

。
├├）node_modules/
pnpm/ .pnpm/
§── .npmrc
§── package.json
pnpm-lock.yml

ロックファイルと依存ストレージ

前のセクションで述べたように、すべてのパッケージマネージャーがロックファイルを作成します。

lockファイルは、プロジェクトによってインストールされたすべての依存関係の正確なバージョンを保存し、より予測可能で決定的なインストールを可能にします。このlockファイルは、依存バージョンがバージョン範囲（≥V1.2.5など）で宣言される可能性が高いため重要です。バージョンを「ロック」しない場合、インストールされている実際のバージョンは異なる場合があります。

ファイルをロックすることも、チェックサム（私が思い出すようにハッシュ）を保存することもあります。これは、セキュリティセクションでより詳細にカバーします。

npm V5+から、ロックファイルは常にnpm package-lock.json pnpm pnpm-lock.yaml機能yarn.lock Yarn Berry

前のセクションでは、 node_modulesフォルダー構造に依存関係をインストールするという従来のアプローチが見られました。これは、 npm 、 Yarn Classic 、および pnpm で使用されるソリューションです ( pnpm他のものより効率的です)。

Yarn Berry 、PNPモードで異なる方法で行います。 node_modulesフォルダーの代わりに、依存関係はzipファイルに.yarn/cache/ and .pnp.cjsファイルの組み合わせとして保存されます。

すべてのチームメンバーが同じバージョンをインストールするため、これらのロックファイルをバージョン制御下に配置する方が良いため、「マシンとマイニングで動作する」問題を解決します。

CLI

次の表は、 npm 、 Yarn Classic 、 Yarn Berry 、およびpnpmで利用可能なさまざまなCLIコマンドを比較しています。これは決して完全なリストではなく、チートシートです。このセクションでは、ワークフロー関連のコマンドをカバーしていません。

npmとpnpm多くのアドホックコマンドとオプションエイリアスがあります。つまり、コマンドは異なる名前を持つことができます。つまり、 $ npm install対$ npm add 。 さらに、多くのコマンドオプションには、 --save-devの代わりに-Dなどのバージョンが省略されています。 テーブルでは、すべての略式バージョンエイリアスを呼び出します。これらの各パッケージマネージャーを使用して、複数の依存関係を追加、更新、または削除できます。

依存関係構成管理

このテーブルは、 package.jsonで指定されたすべての依存関係をインストールまたは更新するために使用される依存関係管理コマンドをカバーします。

インストール構成管理

次の例は、開発中のパッケージの管理方法を示しています。テーブルで使用される用語：

• パッケージ：依存関係またはバイナリ
• バイナリ： node_modules/.bin/ or .yarn/cache/ （pnp）

Yarn Berry package.jsonで実行するか、公開できることを理解することが重要です

bin/ファイルの指定されたバイナリファイル。

commonコマンド

このテーブルは、いくつかの便利な組み込みコマンドをカバーします。公式コマンドがない場合、通常、サードパーティコマンドはnpmパッケージまたはYarn Berryプラグインを介して使用できます。

構成ファイル

Package Managerの構成はpackage.jsonと専用の構成ファイルで発生します。

• 使用する正確なバージョンを定義する
• 特定の依存関係解決戦略で
• プライベートレジストリを構成します
。
• パッケージマネージャーに、Monorepoのmonorepo

npmを

います.npmrc

npmのworkspaces機能を使用する場合は、 package.jsonにワークスペースメタデータフィールドを追加して、NPMにサブプロジェクトまたはワークスペースフォルダーを見つける場所を指示する必要があります。

// ...
  "ワークスペース": [
    「フック」、
    「utils」
  】
}

すべてのパッケージマネージャーは、パブリックnpmレジストリを使用できます。おそらく、それらを公開することなく再利用したいと思うでしょう。これを.npmrcファイルのレジストリをプライベートに設定できます。 （基本的にすべてが現在プライベートソースがあります）

＃.NPMRC
@doppelmutzi：registry = https：//gitlab.doppelmutzi.com/api/v4/projects/41/packages/npm/

npmには多くの構成オプションがあります。ドキュメントで確認するのが最善です。

yarn

yarnのworkspaces package.jsonに設定できます（プライベートパッケージである必要があります）。

{
  // ...
  「プライベート」：本当、
  「ワークスペース」：["Workspace-A"、 "Workspace-B"]]
}

オプションの構成は.yarnrcファイルになります。一般的な構成オプションは、 yarn-path:各チームメンバーに指定されたバイナリバージョンを使用するように強制します。 yarn-path特定のYarnバージョンを含むフォルダーを指しています（例： .yarn/releases/ ）。コマンド（Classic.yarnpkg.com/en/docs/cli…）を使用して、Unified Yarn Classicバージョンをインストールできます。

Yarn Berry

Yarn Berryのワークworkspacesの構成は、 Yarn Classic （ package.json ）の構成に似ています。 ほとんどのYarn Berry構成は.yarnrc.ymlで発生し、多くの構成オプションが利用可能です。

＃.yarnrc.yml
yarnpath：.yarn/leleases/yarn-3.1.1.cjsyarnberry

yarn berry 、インポート方法$> yarn plugin import <name>を使用してプラグイン（yarnpkg.com/cli/plugin/>）を拡張できます。また、更新されます.yarnrc.yml 。

＃.yarnrc.yml
プラグイン：
   - パス：​​.yarn/plugins/@yarnpkg/plugin-semver-up.cjs
    仕様： "https://raw.githubusercontent.com/tophat/yarn-plugin-semver-up/master/bundles/%40yarnpkg/plugin-semver-up.js"

歴史セクションでは、互換性の理由により、 PNP Strictモードの依存関係にいくつかの問題があるかもしれません。このタイプのPNP問題には典型的なソリューションがあります：パケット拡張構成ポリシー。

＃.yarnrc.yml
PackageExtensions：
  「スタイルコンポーネント@*」：
    依存関係：
      React-IS： "*"

PNPM

pnpm npmと同じ構成メカニズムを使用するため、 .npmrcファイルを使用できます。プライベートレジストリの構成もnpm使用するのと同じように機能します。 PNPMのワークスペース機能では、マルチパッケージプロジェクトをサポートできます。 monorepo初期化するには、 pnpm-workspace.yamlファイルのパッケージの場所を指定する必要があります。

＃pnpm-workspace.yaml
パッケージ：
  -  'パッケージ/**'

Monorepo

モノレポとは何ですか

（実際には、単一の倉庫と複数のプロジェクト、単一の倉庫と単一のプロジェクト、複数の倉庫と複数のプロジェクトがあります）

monorepoは、これらのプロジェクトを含むworkspaceです。複数のリポジトリを使用する代わりに、すべてを1か所に保つことは、プロジェクト組織戦略です。

もちろん、これは追加の複雑さをもたらします。 Yarn Classicこの機能を有効にした最初のものでしたが、現在、すべての主要なパッケージマネージャーがワークスペース機能を提供しています。このセクションでは、それぞれの異なるパッケージマネージャーを使用してワークスペースを構成する方法を示します。

NPM

npmチームは、V7で待望のNPMワークスペース機能をリリースしました。ルートパッケージからのマルチパッケージプロジェクトの管理を支援する多くのCLIコマンドが含まれています。ほとんどのコマンドは、 workspaceに関連するオプションで使用でき、特定のワークスペース、複数、またはすべてのワークスペースに対して実行する必要があるかどうかをnpmに伝えることができます。

＃すべてのワークスペースのすべての依存関係をインストールします
$ npm i -workspaces。
＃1つのパッケージに対して実行します
$ npm run test -workspace = hooks
＃複数のパッケージに対して実行します
$ npm run test -workspace = hooks -workspace = utils
＃すべてに対して実行します
$ npm run test -workspaces
#ignoreすべてのパッケージがありませんテストはありません
$ npm run test -workspaces-if-present

Tips：他のパッケージマネージャーと比較して、 npm V8は現在、複数のワークスペース関連コマンドの高度なフィルタリングまたは並列実行をサポートしていません。

Yarn

2017年8月、 Yarnチームはワークスペース機能のmonorepoサポートを発表しました。以前は、パッケージマネージャーは、Lernaなどのサードパーティソフトウェアを使用してマルチパッケージプロジェクトでのみ使用できました。 Yarnへのこの新しい追加は、他のパッケージマネージャーがそのような機能を実装する方法を舗装します。

興味がある場合は、Yarn Classicのワークスペース機能の使用方法を参照することができます。しかし、この記事では、 Yarn Classic Workspaceのセットアップで依存関係を管理するのに役立つ必要なコマンドのみを紹介します。

＃すべてのワークスペースのすべての依存関係$ YARNをインストールします 
＃依存関係のツリー$ YARNワークスペース情報を表示します 
＃別のパッケージを実行して$ YARN Workspace Awesomeを起動する - パッケージ開始
  ＃ウェブパックをパッケージに追加する$ YARNワークスペースAwesome -PackageAdd -D webpack
  ＃すべてのパッケージにReactを追加$ YARN ADD REACT -W

YARN BERRY

Yarn Berryその実装がYarn Classicの概念に基づいて構築されているため、最初からワークスペースを掲載しています。 Redditのコメントで、Yarn Berryのリード開発者は、

• 次
• の
• ような

• 単一のワークスペースのみの依存関係をインストールする
• $ YARNワークスペースFOREACH：すべてのワークスペースでコマンドを実行

Yarn Berry package.jsonファイルのdependenciesまたはdevDependenciesフィールドで使用できる多数のプロトコルを使用します。その中には、 workspaceプロトコルがあります。

Yarn Classicのワークスペースとは対照的に、 Yarn Berry依存関係がこのmonorepoのパッケージの1つでなければならないことを明確に定義しています。それ以外の場合、バージョンが一致しない場合、 Yarn Berryリモートレジストリからバージョンを取得しようとする場合があります。

{
  // ...
  "依存関係": {
    "@doppelmutzi/hooks"： "workspace：*"、
    「http-server」：「14.0.0」、
    // ...
  }  
}

PNPM

workspace Protocolを介して、 pnpm Yarn Berryと同様のmonorepoプロジェクトに貢献しました。多くのpnpmコマンドは、 monorepoコンテキストで特に役立つ--recursive (-r)または - フィルターオプションを受け入れます。そのネイティブフィルタリングコマンドは、 Lernaを非常に補完します。

＃すべてのワークスペースを剪定します  
pnpm -r exec -rm -rf node_modules && rm pnpm -lock.yaml  
＃scope @doppelmutziですべてのワークスペースのすべてのテストを実行する
PNPM再帰実行テスト - フィルター @doppelmutzi/`

パフォーマンスとディスク効率

パフォーマンスは選択決定の重要な部分です。このセクションでは、小規模で中規模のプロジェクトに基づいたベンチマークを紹介します。サンプルプロジェクトに関するメモを次に示します。

、

• 33
• の依存関係を指定します
• 。

詳細な評価と説明については、プロジェクト1（P1）とプロジェクト2（P2）の結果をご覧ください。

• UC 1：キャッシュ/ストアなし、ロックファイルなし、 node_modulesまたは.pnp.cjs
• UC 2：キャッシュ/ストアプレゼント、ロックファイルなし、 node_modulesまたは.pnp.cjs
• UC 3：キャッシュ/ストアプレゼント、ロックファイルプレゼント、 node_modulesまたは.pnp.cjsなしでは、

Tool Gnomonを使用して、インストール（ yarn | gnomon ）で消費される時間を測定しました。さらに、生成されたファイルのサイズ$ du -sh node_modulesを測定しました。

安全な安全な安全性

npm

npm 、悪いパッケージの処理に関しては少し寛大すぎて、多くのプロジェクトに直接影響を与えるセキュリティの脆弱性に遭遇しました。たとえば、バージョン5.7.0では、Linuxオペレーティングシステムでsudo npmコマンドを実行すると、システムファイルの所有権を変更して、オペレーティングシステムを使用できません。

2018年にビットコインの盗難を含む別の事件が発生しました。 node.jsパッケージイベントストリームは、3.3.6バージョンに悪意のある依存関係を追加しました。この悪意のあるパッケージには、開発者のマシンからビットコインを盗もうとする暗号化方法が含まれています。

これらの問題を解決するために、新しいnpmバージョンは暗号化アルゴリズムを使用して、インストールされたパッケージの整合性を確認します。 SHA-512。

Yarn

Yarn ClassicとYarn Berryチェックサムを使用して、最初からすべてのパッケージの完全性を検証します。また、 Yarn 、 package.jsonで宣言されていない悪意のあるパッケージの取得を防止しようとします。JSON：不一致が見つかった場合、インストールは中止されます。

PNPモードのYarn Berryには、従来のnode_modulesメソッドのセキュリティ問題はありません。 Yarn Classicと比較して、 Yarn Berryコマンド実行のセキュリティを改善します。 package.jsonで宣言されたパッケージのみを実行できます。このセキュリティ機能は、以下で説明するpnpmに似ています。

PNPM

pnpmコードを実行する前に、インストールされた各パッケージの整合性を確認するためにチェックサムを使用しています。

上で述べたように、 npmとYarn Classic両方に昇進によりセキュリティの問題があります。 pnpm 、その管理モデルが標高を使用しないnode_modules 、この状況を回避します。これは、依存関係が.package.jsonで宣言されることを意味します。

議論したように、これはmonorepo設定で特に重要です。なぜなら、アルゴリズムを強化すると依存性の非決定につながることがあるからです。

人気のあるプロジェクトの使用

結論は

実際、さまざまなパッケージマネージャーの原則には大きな違いがあります。

pnpm 、CLIの使用量が似ているが、 pnpmのアプローチが非常に異なるため、 npmのように見えます。 Yarn Classicはまだ人気がありますが、レガシーソフトウェアと考えられており、近い将来にサポートが削除される可能性があります。 Yarn Berry PnP真新しいですが、パッケージマネージャーの世界に革命を起こす可能性はまだ再び実現していません。

長年にわたり、多くのユーザーは、どのパッケージマネージャーを使用するかを尋ねてきました。全体的な人々は、 Yarn Berry PnPの成熟度と採用に特に興味を持っているようです。

この記事の目的は、自分で使用するパッケージマネージャーを決定するための複数の視点を提供することです。特定のパッケージマネージャーをお勧めしないことを指摘したいと思います。それはあなたがさまざまな要件をどのように比較検討するかに依存します - あなたはまだあなたが好きなものを選択することができます！

英語のオリジナルアドレス：https：//blog.logrocket.com/javascript-package-managers-compared/