☰

プラグインにnpmでピア依存関係を使用するのはなぜですか? 質問する

tag-icon • tag-icon node.js npm package-managers
プラグインにnpmでピア依存関係を使用するのはなぜですか? 質問する

たとえば、Grunt プラグインが grunt への依存関係を「ピア依存関係」として定義するのはなぜでしょうか?

なぜプラグインはgrunt-plug/node_modules内で Grunt を独自の依存関係として持つことができないのでしょうか?

ピア依存関係については、ここで説明します。https://nodejs.org/en/blog/npm/peer-dependencies/

でも、よく分かりません。

例

私は現在、Grunt タスクを使用してソース ファイルを /dist/ フォルダーにビルドし、ローカル デバイスで提供する AppGyver Steroids を使用しています。私は npm と grunt についてはまったくの初心者なので、何が起こっているのかを完全に理解したいと思っています。

これまでのところ、私はこれを得ました:

[rootfolder]/package.json は、開発用の npm パッケージに依存することを npm に伝えますgrunt-steroids。

  "devDependencies": {
    "grunt-steroids": "0.x"
  },

はい。[rootfolder]で npm install を実行すると依存関係が検出され、[rootfolder]/node_modules/grunt-steroidsに grunt-steroids がインストールされます。

次に、npm は[rootfolder]/node_modules/grunt-steroids/package.jsonを読み取り、独自の依存関係をインストールしますgrunt-steroids。

"devDependencies": {
    "grunt-contrib-nodeunit": "0.3.0",
    "grunt": "0.4.4"
  },
"dependencies": {
    "wrench": "1.5.4",
    "chalk": "0.3.0",
    "xml2js": "0.4.1",
    "lodash": "2.4.1"
  },
"peerDependencies": {
    "grunt": "0.4.4",
    "grunt-contrib-copy": "0.5.0",
    "grunt-contrib-clean": "0.5.0",
    "grunt-contrib-concat": "0.4.0",
    "grunt-contrib-coffee": "0.10.1",
    "grunt-contrib-sass": "0.7.3",
    "grunt-extend-config": "0.9.2"
  },

「依存関係」パッケージは[rootfolder]/node_modules/grunt-steroids/node_modulesにインストールされますが、これは私にとっては論理的です。

「devDependencies」はインストールされていません。これは、私が使用しようとしているだけgrunt-steroidsで、開発しようとしているのではないことを npm が検出することによって制御されていると確信しています。

しかし、" peerDependencies "があります。

これらは[rootfolder]/node_modulesにインストールされますが、他の grunt プラグイン (またはその他) との競合を避けるために[rootfolder]/node_modules/grunt-steroids/node_modulesではなく、そこにインストールされる理由がわかりません。

ベストアンサー1

TL;DR: は、 公開されず実装の詳細のみである「プライベート」peerDependencies依存関係とは対照的に、使用コードに公開され (使用することが予想される) 依存関係用です。

ピア依存関係が解決する問題

NPM のモジュール システムは階層化されています。よりシンプルなシナリオでの大きな利点の 1 つは、npm パッケージをインストールすると、そのパッケージが独自の依存関係を持ち込むため、すぐに使用できることです。

しかし、次のような場合には問題が発生します。

  • プロジェクトと使用しているモジュールの両方が別のモジュールに依存しています。
  • 3 つのモジュールは相互に通信する必要があります。

例

ビルドしていて、と のYourCoolProject両方を使用しているとします。また、も に依存していますが、異なるバージョン、たとえば に依存しているとします。これら 2 つのバージョンが一致しない限り、問題はありません。 が表面下でを使用しているという事実は、単なる実装の詳細です。2回バンドルしていますが、安定したソフトウェアをすぐに入手できるのであれば、これは小さな代償です。JacksModule 1.0JillsModule 2.0JacksModuleJillsModule1.0JacksModuleJillsModuleJillsModule

しかし、JacksModuleが への依存関係を何らかの方法で公開するとどうなるでしょうか。たとえば、JillsModuleのインスタンスを受け入れます... ライブラリのusing バージョンを作成し、それを に渡すとどうなるでしょうか。大混乱が起こります! のような単純なものが突然返されます。これは、 が実際には別のバージョンのインスタンスであるためです。JillsClassnew JillsClass2.0jacksFunctionjillsObject instanceof JillsClassfalsejillsObject JillsClass2.0

ピア依存関係がこれをどのように解決するか

彼らはnpmに言う

このパッケージが必要ですが、私のモジュール専用のバージョンではなく、プロジェクトの一部であるバージョンが必要です。

npm は、パッケージが依存関係のないプロジェクトにインストールされているか、互換性のないバージョンが含まれていることを検出すると、インストール プロセス中にユーザーに警告します。

ピア依存関係はいつ使用すればよいですか?

  • 他のプロジェクトで使用するライブラリを構築する場合、
  • このライブラリは他のライブラリを使用しており、
  • ユーザーが他のライブラリも使用することが期待/必要である

一般的なシナリオは、大規模なフレームワークのプラグインです。Gulp、Grunt、Babel、Mocha などを思い浮かべてください。Gulp プラグインを作成する場合、そのプラグインが、独自のプライベートバージョンの Gulp ではなく、ユーザーのプロジェクトが使用しているのと同じ Gulp で動作するようにする必要があります。

おすすめ記事