JavaScript 開発者として、プロジェクト内の 2 つの異なる依存関係、依存関係と devDependency については誰もが知っていますが、peerDependency についてはどうですか?

このシリーズでは、JavaScript におけるこのあまり一般的ではない依存関係を調べます。私たちは、それらが何であるか、図書館ユーザーとして知っておくべきこと、そして図書館作成者にとってのベストプラクティスとは何かを学びます。

NPM の依存関係とは何ですか

さまざまな一般的なタイプをまとめてみましょう:

• 依存関係: これらはアプリケーションで使用されるツールです。良い例は、react、angular、express です。アプリケーションが運用環境にある場合、依存関係にあるライブラリのコードが内部で実行され、アプリケーションが強化されます。

• devDependency: これらのユーティリティを使用してアプリケーションを構築します。ここには、コードをコンパイルまたは解析するためのライブラリと、テストを実行するためのライブラリがあります。

ピア依存関係とは

作成者は、すべてが期待どおりに動作するために特定のライブラリをワークスペース/プロジェクトにインストールする必要がある場合、peerDependency として指定します。これらは、NPM (およびライブラリをインストールする開発者) に、パッケージが正しく機能するには別のパッケージの特定のバージョン (またはバージョンの範囲) が必要であることを伝えます。ただし、その依存関係のインストールと管理はユーザーの責任です。

例を想像してみましょう。お気に入りのフレームワーク用のユーティリティを作成しています。これは、ライブラリが実行される環境にインストールする必要があります。このシナリオを正確に指定する方法は、NPM のpeerDependency 機能を使用することです。これは、ライブラリをシームレスに統合するための明確なガイドラインを提供します。

この手法は、適切な機能のためのワークスペース要件を示す必要があるため、「プラグイン」として機能するライブラリで特に一般的です。

peerDependency の実際の例

人気のある React ライブラリ、react-datepicker を分析してみましょう。現在の package.json の様子を見ると、react-date picker が正しく動作するには、少なくとも React バージョン ^16.9.0 が必要であることがわかります。

"peerDependencies": {
  "react": "^16.9.0 || ^17 || ^18",
  "react-dom": "^16.9.0 || ^17 || ^18"
},

この要件に従わない場合、予期しない動作が発生する可能性があります。

課題peerDependencyアドレス

プロジェクト内のパッケージが同じライブラリの異なるバージョンに依存している場合、バージョンの競合が発生します。これは、特に React のようなライブラリの場合、同じインスタンスの共有が状態管理とコンポーネントの通信にとって重要であるため、エラーにつながる可能性があります。 peerDependency がないと、複数のライブラリ バージョンがインストールされ、予期しない動作が発生する可能性があります。

これらの問題を防ぐために、peerDependency を使用すると、パッケージ作成者は、パッケージを直接インストールせずに、パッケージに必要な依存関係のバージョンを指定できます。これにより、パッケージを使用する開発者に責任が移り、開発者は単一の互換性のある依存関係バージョンを確実にインストールできるようになります。たとえば、react-datepicker や react-router などのライブラリは、peerDependency を使用して、プロジェクト内の同じバージョンの React とシームレスに動作することを保証します。

別の例

次のシナリオを想像してください: rxjs の派手な演算子を共有するライブラリを作成しています。 rxjs をpeerDependency ではなく依存関係として設定すると、ライブラリは独自のバージョンの rxjs をインストールします。これは最初は大したことではないように思えるかもしれませんが、実際にはバージョンの競合を引き起こす可能性があります。

ライブラリをインストールするプロジェクトがすでに別のバージョンの rxjs を使用している場合、重大な問題が発生する可能性があります。アプリケーションには、rxjs の 2 つのインスタンス (ライブラリから 1 つとプロジェクト自体から 1 つ) が作成される可能性があります。 rxjs は共有オブザーバブルとサブスクリプションに大きく依存しているため、2 つのバージョンを同時に実行すると、ストリームが適切に同期しなかったり、イベントが欠落したりするなど、予期しない動作が発生する可能性があります。

代わりにpeerDependencyを使用すると、この問題を回避できます。パッケージは、rxjs の特定のバージョン (または範囲) が存在することを期待していることをプロジェクトに通知しますが、独自のバージョンはインストールしません。このようにして、プロジェクトはライブラリとコードベースの他の部分で共有される単一バージョンの rxjs を使用し、すべてがスムーズかつ調和して実行されるようにします。

結論

peerDependency は、依存関係や devDependency ほど一般的に議論されることはないかもしれませんが、複雑なプロジェクトで互換性を確保し、バージョンの競合を回避する上で重要な役割を果たします。ライブラリを直接インストールせずに、ライブラリに必要な共有依存関係のバージョンを明確に定義することで、peerDependency を使用すると、開発者がプロ​​ジェクト環境の制御を維持できるようになります。

この最初の投稿の目標は、peerDependency をよく理解するための基盤を作成することです。このシリーズの次の章では、peerDependency を含むライブラリのユーザーとしての PeerDependency のさまざまな側面、一般的な問題の克服方法、およびそれらがさまざまな JavaScript パッケージ マネージャーでどのように動作するかについて、より実践的な方法で検討していきます。