web-dev-qa-db-ja.com

Npm package.jsonファイルの依存関係、devDependencies、およびpeerDependenciesの違いは何ですか？

このドキュメンテーション は私の質問にはほとんど答えない。私はそれらの説明がわかりませんでした。誰かが簡単な言葉で言うことができますか？単純な言葉を選ぶのが難しい場合は、例を挙げて説明します。

_ edit _ もpeerDependenciesを追加しました。これは密接に関連しており、混乱を招く可能性があります。

node.jsnpm
1728
Vitalii Korsakov

重要な動作の違いの要約

  • dependencies は両方にインストールされます。

    • npm installを含むディレクトリからのpackage.json
    • 他のディレクトリのnpm install $package

  • devDependencies は次のとおりです。

    • npm installフラグを渡さない限り、package.jsonを含むディレクトリの--productionにもインストールされます（up _vote Gayan Charith's answer ）。
    • npm install "$package"オプションを指定しない限り、他のディレクトリの--devにはインストールされません。
    • 他動詞的にインストールされていません。

  • peerDependencies ：

    • 3.0より前：存在しない場合は常にインストールされ、依存関係の互換性のない複数のバージョンが異なる依存関係によって使用される場合はエラーが発生します。
    • 3.0から開始する予定 （未テスト）：npm installがない場合は警告を出します。依存関係は手動で解決する必要があります。実行時に依存関係が欠けているとエラーになります（ @nextgentech で説明されています）

  • 推移性（ Ben Hutchison で言及）：

    • dependenciesは推移的にインストールされます。AがBを必要とし、BがCを必要とする場合、Cはインストールされます。そうでなければ、Bは機能せず、Aも機能しません。

    • devDependenciesは推移的にインストールされていません。例えば。 AをテストするためにBをテストする必要はないので、Bのテスト依存関係は省くことができます。

ここでは説明しない関連オプション

devDependencies

dependenciesは実行に必要で、devDependenciesは開発にのみ必要です。例：ユニットテスト、CoffeeScriptからJavaScriptへの変換、縮小、...

あなたがパッケージを開発するつもりなら、あなたはそれをダウンロードし（例えばgit clone経由で）、package.jsonを含むそのルートに行き、そして以下を実行してください：

npm install

あなたは実際のソースを持っているので、あなたがそれを開発したいのは明らかです、それでデフォルトで、dependencies（もちろん開発のために走らなければならないので）とdevDependencyの依存関係もインストールされます。

しかし、あなたがそれを使うためにパッケージをインストールしたいだけのエンドユーザーであれば、あなたはどんなディレクトリからでもそうするでしょう：

npm install "$package"

その場合、通常は開発依存関係は必要ないので、パッケージを使用するために必要なものはdependenciesだけになります。

そのような場合に開発パッケージを本当にインストールしたい場合は、dev設定オプションをtrueに設定することができます。おそらくコマンドラインから次のようにします。

npm install "$package" --dev

これはあまり一般的ではないため、このオプションはデフォルトでfalseです。

peerDependencies

（3.0より前にテスト済み）

ソース： https://nodejs.org/ja/blog/npm/peer-dependencies/

通常の依存関係では、依存関係の複数のバージョンを持つことができます。依存関係のnode_modules内に単純にインストールされます。

例えば。 dependency1とdependency2がどちらも異なるバージョンのdependency3に依存している場合、プロジェクトツリーは次のようになります。

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

ただし、プラグインは通常他のパッケージを必要としないパッケージです。このパッケージでは Host と呼ばれます。代わりに：

  • プラグインが必要です ホスト側
  • プラグインは、ホストが見つけることを期待している標準インターフェースを提供します。
  • ホストだけがユーザーによって直接呼び出されるので、それの単一のバージョンがなければなりません。

例えば。 dependency1とdependency2 peerがdependency3に依存している場合、プロジェクトツリーは次のようになります。

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

dependency3ファイルにpackage.jsonが記載されていなくても、これは起こります。

これは Inversion of Control デザインパターンのインスタンスだと思います。

ピアの依存関係の典型的な例は、Grunt、Host、およびそのプラグインです。

たとえば、 https://github.com/gruntjs/grunt-contrib-uglify のようなGruntプラグインでは、次のようになります。

  • gruntはpeer-dependencyです
  • 唯一のrequire('grunt')はtests/の下にあります。実際にはプログラムによって使用されていません。

その後、ユーザーがプラグインを使用するときは、grunt.loadNpmTasks('grunt-contrib-uglify')行を追加して暗黙的にGruntfileからプラグインを要求しますが、ユーザーが直接呼び出すのはgruntです。

各プラグインが異なるGruntバージョンを必要とする場合、これは動作しません。

マニュアル

私はドキュメンテーションが質問に非常によく答えると思います、多分あなたはノード/他のパッケージマネージャに十分に精通していないだけかもしれません。私はRubyバンドラーについて少し知っているので、おそらくそれだけを理解するでしょう。

重要な行は次のとおりです。

これらのものは、パッケージのルートからnpm linkまたはnpm installを実行するときにインストールされ、他のnpm設定パラメータと同様に管理できます。このトピックに関する詳細はnpm-config（7）を参照してください。

そしてnpm-config（7）の下にdevを見つけます。

Default: false
Type: Boolean

Install dev-dependencies along with packages.
1969
Ciro Santilli 新疆改造中心 六四事件 法轮功

DevDependenciesをインストールしたくない場合は、npm install --productionを使用できます。 

402
Gayan Charith

一例として、テストは本番環境では必要ないのでmochaは通常devDependencyですが、expressは依存関係です。 

95
dankohn

パッケージをdevの依存関係として package.json に保存するには： 

npm install "$package" --save-dev

npm installを実行すると、devDependenciesとdependenciesの両方がインストールされます。インストールdevDependenciesを回避するには、次のコマンドを実行します。

npm install --production
55
Mohammed Safeer

依存関係
コードから呼び出す関数を提供するライブラリなど、プロジェクトの実行に必要な依存関係。
これらは推移的にインストールされます（AがBに依存してCに依存する場合、AにnpmをインストールするとBとCがインストールされます）。
例：lodash：プロジェクトはいくつかのlodash関数を呼び出します。

devDependencies
開発中またはリリース中にのみ必要な依存関係。コードを取得してJavascriptにコンパイルするコンパイラ、テストフレームワーク、ドキュメントジェネレータなど。
[。
例：grunt：プロジェクトは自身のビルドにgruntを使用します。

peerDependencies
プロジェクトが親プロジェクトにフックまたは変更する依存関係。通常、他のライブラリまたはツールのプラグインです。これは、親プロジェクト（プロジェクトに依存するプロジェクト）がフック先のプロジェクトに依存していることを確認するためのチェックです。したがって、ライブラリBに機能を追加するプラグインCを作成する場合、プロジェクトAを作成する人は、Cに依存している場合はBに依存する必要があります。
これらはインストールされず（npm <3でない場合）、チェックされるだけです。
例：grunt：プロジェクトはgruntに機能を追加し、gruntを使用するプロジェクトでのみ使用できます。

このドキュメントは、ピアの依存関係を本当によく説明しています： https://nodejs.org/en/blog/npm/peer-dependencies/

また、npmのドキュメントは時間が経つにつれて改善され、さまざまな種類の依存関係の説明が改善されました。 https://github.com/npm/cli/blob/latest/doc/files/package.json .md＃devdependencies

53
qwertzguy

開発にのみ必要なモジュールやパッケージがいくつかありますが、本番では必要ありません。 ドキュメンテーション ：に書かれているように

誰かがあなたのモジュールをダウンロードして自分のプログラムで使うことを計画しているなら、おそらく彼らはあなたが使う外部テストやドキュメンテーションフレームワークをダウンロードして構築することを望んでいないし、必要としません。この場合、これらの追加項目をdevDependenciesハッシュにリストするのが最善です。

33
Amberlamps

私にとってより明確にした簡単な説明は次のとおりです。

アプリをデプロイするときは、依存関係にあるモジュールをインストールする必要があります。そうしないと、アプリは機能しません。 devDependenciesのモジュールは、あなたがそのマシン上で開発していないので、本番サーバーにインストールする必要はありません。 link

11
Jyoti Duhan

これらの依存関係の説明に対する私の見解を答えに加えたいのですが

  • dependenciesは、コードベースで直接使用するために使用されます。通常は本番用コードに含まれるもの、またはコードの塊です。
  • devDependenciesはビルドプロセス、エンドコードがどう終わるかを管理するのに役立つツール、サードパーティのテストモジュールに使われます（例：webpackもの）
8
Sîrbu Nicolae-Cezar

peerDependenciesは、このスニペットを ブログ投稿 トピック 上記のCiro ：から読むまで意味がありませんでした。

[plugins]が必要とするのは、プラグインとホストパッケージ間のこれらの「依存関係」を表現する方法です。 「ホストパッケージのバージョン1.2.xに接続した場合にのみ機能するため、互換性のあるホストと一緒にインストールするようにしてください。」この関係をピア依存関係と呼びます。

プラグインはexpect特定のバージョンのホスト...

peerDependenciesはプラグイン用で、機能を実行するために「ホスト」ライブラリを必要とするライブラリですが、一度に記述されている場合がありますbeforeホストの最新バージョンがリリースされました。

つまり、PluginX v1のHostLibraryX v3を書いて、立ち去っても、PluginX v1（またはHostLibraryX v4）がリリースされたときにHostLibraryX v3.0.1が機能するという保証はありません。

...しかし、プラグインはdependホストではありません...

プラグインの観点から見ると、それはaddsのみがホストライブラリに機能します。プラグインに依存関係を追加するためにホストを実際に「必要」にすることはありません。また、プラグインはしばしばホスト上で文字通りdependしません。ホストがない場合、プラグインは無害に何もしません。

これは、dependenciesが実際にはプラグインの正しい概念ではないことを意味します。

さらに悪いことに、私のホストが依存関係のように扱われた場合、この状況になります 同じブログ投稿の言及 （この回答のホストとプラグインを使用するために少し編集しました）：

しかし、[HostLibraryXの最新バージョンをPluginXの依存関係として扱う場合] npm installを実行すると、予期しない依存関係グラフが生成されます

├── [email protected]
└─┬ [email protected]
  └── [email protected]

メインアプリケーションとは異なる[HostLibraryX] APIを使用するプラグインに起因する微妙な失敗は、想像してみてください。

...そして、ホストは明らかにプラグインに依存していません...

...それがプラグインのポイントです。ホストが、プラグインのallの依存関係情報を含めるのに十分であれば、それで問題は解決しますが、それは巨大な新しい文化的問題をもたらします：プラグイン管理！

プラグインの全体的なポイントは、匿名でペアリングできることです。完璧な世界では、ホストがそれらをすべて管理することはきちんと整頓されますが、図書館の群れ猫を必要としません。

階層的に依存していない場合、おそらく内部依存のピアです...

代わりに、ピアになるという概念があります。ホストもプラグインも、相手の依存関係バケットにありません。両方とも依存グラフの同じレベルに存在します。

...しかし、これは自動化可能な関係ではありません。

私がPluginX v1かつexpectのピア（つまり、peerDependency of]）HostLibraryX v3である場合、そう言います。最新のHostLibraryX v4に自動アップグレードした場合（バージョン4に注意してください）およびPlugin v1がインストールされています。知っておく必要がありますか？

npmはこの状況を管理できません-

「ねえ、あなたはPluginX v1を使用していることがわかります！HostLibraryXをv4からv3に自動的にダウングレードしていますか？」

...または...

「ねえ、あなたはPluginX v1を使用しているのを見る。それはHostLibraryX v3を期待している。あなたは最後のアップデートでほこりに残った。安全のために、Plugin v1-を自動的にアンインストールする!! 1！

いいえ、npmはどうですか？！

したがって、npmはそうではありません。状況を警告し、HostLibraryX v4がPlugin v1の適切なピアであるかどうかを判断できます。

コーダ

プラグインの優れたpeerDependency管理により、この概念は実際にはより直感的に機能します。 ブログ投稿 から、もう一度...

1つのアドバイス：通常の依存関係の要件とは異なり、ピアの依存関係の要件は寛大でなければなりません。特定のパッチバージョンにピアの依存関係をロックしないでください。あるプラグインがChai 1.4.1に依存している一方で、別のプラグインがChai 1.5.0に依存している場合、単に作者が怠け者であり、実際の最小バージョンのChaiと互換性があります。

3
ruffin

依存関係と開発者の依存関係

開発依存関係は開発時にのみ必要なモジュールですが、実行時には依存関係が必要です。アプリケーションをデプロイする場合、依存関係をインストールする必要があります。そうしないと、アプリが機能しなくなります。プログラムを実行できるようにするコードから呼び出すライブラリは、依存関係と見なすことができます。

Eg- React、React-dom

コードをjavascriptに変換するマシン.compiler、テストフレームワーク、およびドキュメントジェネレーターは開発中にのみ必要であるため、dev依存モジュールと見なすことができるため、開発サーバーに開発依存モジュールをインストールする必要はありません。

例：ESLint、Babel、webpack

@FYI、

mod-a
  dev-dependents:
    - mod-b
  dependents:
    - mod-c

mod-d
  dev-dependents:
    - mod-e
  dependents:
    - mod-a

----

npm install mod-d

installed modules:
  - mod-d
  - mod-a
  - mod-c

----

checkout the mod-d code repository

npm install

installed modules:
  - mod-a
  - mod-c
  - mod-e

Npmに公開する場合、正しいモジュールに正しいフラグを使用することが重要です。 npmモジュールが機能する必要がある場合は、「-save」フラグを使用して、モジュールを依存関係として保存します。モジュールが機能する必要はないが、テストには必要な場合は、「-save-dev」フラグを使用します。

# For dependent modules
npm install dependent-module --save

# For dev-dependent modules
npm install development-module --save-dev
2
Selva Ganapathi

Npmパッケージを配布することを試みるときあなたはdependenciesの使用を避けるべきです。代わりにpeerDependenciesに追加するかdependenciesから削除することを検討する必要があります。

0
Melchia

要するに

  1. 依存関係 - 本番環境でアプリケーションに必要なnpm install <package> save-prod instalslパッケージ。

  2. DevDependencies - npm install <package> --save-devは、ローカルの開発とテストにのみ必要なパッケージをインストールします

  3. npm installと入力するだけで、package.jsonに記載されているすべてのパッケージがインストールされます。

ローカルコンピュータで作業している場合は、npm installと入力して続行してください。

0
cherankrish