Yarn: 開発/テスト用にパッケージピアの依存関係をインストールする手段を追加する

@ jpollard-csパッケージをピア依存関係として追加することについて言及しているのではなく、現在ピア依存関係としてリストされているすべてのパッケージをインストールする手段があることについて言及しています。
そうでなければ、プラグインを開発する実行可能な手段はありません。

npm install
package.jsonの依存関係セクションで宣言されているすべてのパッケージをインストールします。

yarn add --peer
これにより、package.jsonpeerDependenciesセクションで宣言されたすべてのパッケージがインストールされると期待していました。

宣言されたパッケージをpeerDependenciesにインストールする方法はありますか？

私のユースケースは、ReactNativeモジュールの開発/テストです。

これが彼らがクローズしたNPMの問題です： https ：

どうやらNPM開発者にとって重要ではありません。

+1これは図書館の作者にとって重要です

私はすでにNPMの問題についてこれを書いていますが、Yarnの人々のために：

パッケージのピア依存関係をインストールするCLIプログラムを作成しました。

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

問題がある場合は、レポで問題を開いてください。

@nathanhleung 、そのパッケージはすべての依存関係ピア依存関係をインストールしているように見えます。 これは、このチケットの内容ではありません。 これは、独自のパッケージのピア依存関係のインストールに関するものです。

それを行うためのパッケージで修正しましたhttps://www.npmjs.com/package/@team-griffin/install-self-peers

@nathanhleungあなたはロックします。

うーん...開発/テストのために依存関係が必要な場合、それらをdevDependencies下に置くべきではありませんか？ 爆弾などを落とそうとしない...

@nikolakanackiどこから来たのかを完全に開発依存関係を強制的にインストールさせてはならないため、ピア依存関係と

@nikolakanackiユーザーがインストールする別のパッケージに依存するパッケージを

ユースケースeslint-find-rules

パッケージは、構成で構成されていないESLintで使用可能なルールを検索します。
ユーザーにとって意味のあるものにするためには、インストールされているESLintパッケージを確認する必要があり、パッケージに付属している特定のバージョン（またはlatest ）ではありません。
つまり、これはpeer依存関係です。

プロジェクトに貢献したい場合は、ESLintをnode_modulesにインストールして、ESLintをインストールするダミープロジェクトでnpm-linkを実行せずに、コードをテストできるようにします。

ユーザーがyarnと、システムはピアdepsをインストールして、それらが欠落していることを警告するべきではありません（これは機能します）。

だから...まだインストールされていない場合にyarnがピアデップをインストールするようにするフラグは親切にその問題を解決するでしょう。

興味深い点

• yarn add <package> --peerはそれをnode_modulesにインストールし、package.jsonに追加します
• その後、 yarn add <other_package>は、インストールされているパッケージをnode_modulesから削除します

私は現在@nikolakanackiモデルを機能しているようです。 私はそれが混乱する可能性があることに同意し、 yarn install --peer dependencies 、 devDependencies 、およびpeerDependenciesをインストールするためにyarn install --peerを好むが、これは私にとって同じように機能する。

私はこの権利@kyleholzinger / @gaastonsrを得ている場合は、インストールして見ていないpeerDependencies開発モードで（ cd -edレポ/パッケージにありpeerDependencies 、新しいクローン、それらのピア部門で開発する必要があります）が、ピア部門を持つパッケージをインストールしたら、それらをターゲットプロジェクトに追加しますか？

明確にするために：依存関係としてeslintが必要であると文句を言うeslint-find-rulesをインストールする（これはeslint-find-rules peerDependencyです）ので、今度は簡単な方法が必要ですあなたが取り組んでいるpeer （ eslint-find-rules依存する現在のプロジェクト）にそれらの依存関係を追加するのですか？ 「現在の依存関係に必要な、最も一致するピアの依存関係を解決して新しい依存関係として追加（ package.jsonとyarn.lock ）」のようなものですか？

これがあなたのポイントであるならば、それは非常に役に立つかもしれません、私はあなたが開発するときにそれらを自動インストールすることを参照していると思いました。

この機能は、純粋な利便性よりも多くの目的で導入できます。たとえば、複数の依存関係がピアターゲットの同じパッケージに依存している可能性がありますが、異なるバージョンが必要です。この機能は、単一のベストに解決しようとすることで、この機能を最大限に活用できます。 -一致するターゲット（可能な場合）。

間違いなく考えるべきこと。

これがあなたのポイントであるならば、それは非常に役に立つかもしれません、私はあなたが開発するときにそれらを自動インストールすることを参照していると思いました。

これが私が探しているものです。 パッケージを開発しているときにpeerDependenciesをインストールします。

ええ、まさに@nikolakanacki！ 仲間の部署の管理を手伝う絶好の機会があると感じています。

@gaastonsrはそれをdevDependenciesに追加する必要があります-それはそれと同じくらい簡単です。 それ以外の場合、パッケージは開発のために壊れています。 プロジェクトのクローンを作成してyarnを実行すると、すべてがインストールされ、テストなどを実行できるようになります。

次のような場合に、依存関係をインストールする前に尋ねる必要がある2つの単純でまったく関係のない質問：

1. 私のパッケージはこのパッケージに依存していますが、私のパッケージはそのパッケージの単なるプラグインであるため、ターゲットプロジェクトに含まれていると思います。 peerDependencies入れてください。
2. このパッケージに依存するテストがありますが、何らかの理由でdependenciesリストされていません（リストされるべきではありません）： devDependencies入れてください。

言い換えると、開発中に存在すると予想され、開発中のパッケージの直接の依存関係としてリストされていないすべてのパッケージは、 devDependencies存在する必要があります。 重複は問題ではありません-ドキュメントのどこにも、これらの場合に重複が許可/推奨されていないことは記載されていません。

@nikolakanackiパッケージのプラグインを作成するときは、ユーザーがインストールしたパッケージのバージョンに依存する必要があります。 devDependencyとして追加すると、必然的に別のバージョンがインストールされ、代わりに使用されます。ユーザーのバージョン。

依存関係を*として定義しない限り、Yarnは何らかの形で決定論的であり、ユーザーがインストールしたパッケージを優先する必要があります。

現在はそうではありません：

• https://github.com/yarnpkg/yarn/issues/3793
• https://github.com/yarnpkg/yarn/issues/3778

@alexilyaev @nikolakanackiは、peerDependencyとdevDependencyの両方としてインストールすることを意味すると思います。

これには、両方の同期を維持する必要があるという問題があります。 私にとっては今のところうまくいきますが、理想的ではないと思います。

@alexilyaev peerDependencyを宣言すると、そのバージョンも宣言します。 ターゲットプロジェクトに、定義したバージョンも満たすピア依存関係のバージョンがインストールされていない限り、 yarn / npmはエラーを報告します（ピア依存関係がない、など）。

それ以外のdevDependencyはそれとは何の関係もありません、それはソースパッケージ内でyarnまたはnpm install実行するときにインストールされるものです（ピアの依存関係を宣言するもの、例えば：プラグイン）、およびパッケージがサードパーティのパッケージ/プロジェクト（ピア）によって使用されている場合でも参照されません。

重要なのは、これがどのように関連しているかわからないということです。

それらを同期させることの苦痛を見ることができますが、これをインストール後のステップとしてチェックするbash / javascript / <whatever>スクリプトを簡単に書くことができます。 package.json 。

私が言いたいのは、 devDependencies感情を壊してはいけないということです。さらに悪いことに、「 yarnまたはnpm installしても、必ずしもすべてがインストールされるわけではありません。このパッケージの必要な依存関係」の概念。

一方、 yarnは、これに関してさらに厳格なポリシーを導入しました。これにより、 dependenciesまたはdevDependenciesとして定義されていないパッケージがクリアされるため、実行されません。後で問題に。

@nikolakanackiプラグインが^7.0.0を受け入れ、最新のピアが7.9.0で、ユーザーがpackage.json 7.4.0定義されているとします。
devDependenciesにも^7.0.0がある場合、Yarnは7.9.0と7.4.0両方を（ユーザー用に）インストールしませんか？

もしそうなら、私のプラグインは7.4.0代わりにインストールされた7.9.0誤って使用するかもしれません。

@alexilyaevパッケージは、他の場合と同様に、このピア部門のパッケージで定義されている

もっと具体的に言いたいのですが、あなたが提示した事例がよくわかりません。明確にしていただけませんか。

〜 peerDependency非互換性があり、プラグインは^7.0.0を想定し、バージョン7.4.0があることを警告します。〜更新： ^7.0.0は7.4.0満たします

Yarnは7.9.0と7.4.0の両方を（ユーザー向けに）インストールしませんか？

YarnはpeerDependenciesをインストールせず、プラグインのdevDependenciesをインストールせず、 dependencies依存関係だけをインストールします。

@gaastonsr ^7.0.0が7.4.0によって満たされることを除いて、あなたは絶対に正しいです。

パッケージがメインパッケージでない場合、ピアの依存関係はデフォルトでインストールされません。開発の依存関係はインストールされません。 「エンドユーザー」は、プロジェクトの通常の「依存関係」に範囲とともに追加することにより、満たす必要のあるピアの依存関係を定義する必要があります。 プラグインで必要な「semverrange」を満たすことも満たさないこともあり、ユーザーには後者が通知されます。

npmによって説明されているSemverの範囲： https ：//docs.npmjs.com/misc/semver
疑わしい場合は常に確認してください： http ：

@nikolakanackiがパッケージのpeerdependenciesを簡単にインストールできるのは素晴らしいことです！

@nikolakanackiわかりました。実際、エンドユーザーがパッケージをインストールしても、 devDependenciesはインストールされないため、パッケージの作成者はpeerDependenciesをdevDependenciesにも追加する必要があります。

したがって、これはローカル開発の問題を解決します。

しかし、多くのプロジェクトがピア依存関係を開発依存関係として追加しなかったようです。
ですから、私たちはその言葉を広め始め、プロジェクトを参加させるべきだと思います。
これは必然的に、なぜそれがnpmで機能し、Yarnでは機能しないのかについての長い議論につながります。結果に関係なく、時間がかかり、すべてのプロジェクトが変更を行うとは限りません。

だから...少なくともピアの依存関係をインストールする方法をサポートすることを提案しているので、少なくともinstall-peerdepsを使用する必要

ここで実際の問題は何ですか？ ある部門のリストをインストールすることは、別の部門のリストをインストールするよりも複雑になるとは思われません。 ピアの依存関係は数年前から存在しています。 これはどのように誰も気にしませんでしたか？

@nikolakanackiソリューションは完全に理にかなっています。 これは、ライブラリ開発に使用しているものです。 分離テスト（必要なpeerDependenciesを提供するホストプロジェクトの外部）のためにライブラリでdevDependencies適切にセットアップする必要があり、統合テストとホストを確認するためにpeerDependenciesが必要ですプロジェクトが消費するライブラリは同じdependenciesを使用しており、 peerDependenciesとdevDependenciesを適切に使用していないため、プロジェクトは冗長/重複したパッケージのインストールになり

それらを同期させることには小さな頭痛の種があります。 しかし、 @ nikolakanackiが指摘したように、これはpost-installスクリプトを使用することで簡単に軽減できます。

どのような解決策ですか？

私はコメントを十分に速く実行しましたが、簡単な解決策に気づきませんでした：

トップレベルのパッケージに含まれている場合は、常にpeerDependenciesを通常の依存関係としてインストールしてください

開発/テストケースに完全に適合し、依存関係としてパッケージのインストールに影響を与えません。 糸.lockのロジックと同様です。 追加の「開発」やその他のモードは必要ありません。

実際、peerDependenciesに関連する他のヤーンのバグのために、場合によっては正確に動作しているように見えます。

非常に同意しました。リポジトリで「yarninstall」を実行すると、depsにまだリストされていないピアの依存関係がインストールされます。 その点で、開発者の依存関係とどのように違うのかはわかりません。そのモジュールで開発している場合は、これらのモジュールをインストールする必要があります。

問題が何であるか、提案された解決策がある場合はそれが何であるかを明確に把握できないため、これを閉じます。

説明を追加するか、新しいバグを報告して、自由に再開してください。

@BYKは、55の親指を立て、34のコメントを付けて問題を解決していることを本当に確信していますか？

非常に簡単だと思います。
または、別の言い方をすると、現在のパッケージに設定されている場合、peerDependenciesを通常の依存関係として扱います。

このスレッドでさらに提案されているように、ピアの依存関係を開発の依存関係としても追加すると、flow-typedが壊れます： //github.com/flowtype/flow-typed/issues/379

@andvgal私は問題を整理しようとしているだけで、数か月前からのここでのすべての議論は圧倒的で要約するのが困難でした。

非常に簡単だと思います。トップレベルのパッケージに設定するときに、peerDependenciesがインストールされていることを確認してください。
または、別の言い方をすると、現在のパッケージに設定されている場合、peerDependenciesを通常の依存関係として扱います。

これは素晴らしい要約でしたありがとうございます。 問題を再開しますが、そのようにする場合は、デフォルトでpeerDependenciesをインストールすることの影響について慎重に検討する必要があります。

または、少なくとも、package.jsonファイルに触れることなくピアの依存関係を個別にインストールする方法を提供します。 addを使用してピア依存関係をインストールすると、JSONファイルのエントリが変更されます。 semver式を、yarnがデフォルトで書き込む方法とは異なる方法で設定した場合、それは変更されます。

--peerスイッチを追加してインストールするというアイデアは問題ないと思いますが、これらのモジュールのいくつかを頻繁にリンクし、リンクと実際の間を行ったり来たりするので、実際には1つずつインストールできるようにしたいと思います。モジュールをインストールします。 npmを使用すると、 'npmiを実行できます。'。 ヤーンでは、同等のものは見当たりません。 具体的には、package.jsonファイルを変更せずに、package.jsonの仕様を使用して1つのファイルをインストールできるようにしたいです。

@jimsugg 、私はyarn add <package...> -pを使用して、package.jsonにすでにリストされているピアの依存関係を手動でインストールしています。これは間違いなくアンチパターンです。 ピアの依存関係は開発環境に自動的にインストールされる必要があるようです（実際にピアの依存関係である場合は、少なくともパッケージを必要とするテストが必要です）。

私は同じものを探していて、リストされているすべてのピア部門をインストールするためにこのBashワンライナーを思いつきました（jqをインストールする必要があります）： yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) 。

これが他の誰かに役立つことを願っています。

@EdwardDrapkinそれをありがとう、伝説的なアイデア！ 私はそれを拡張し、これを行うためにnpmスクリプトを追加することになりました：

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

peerDependenciesのバージョン仕様も維持するだけです;） latestタグを使用したくない場合は、ここで問題が発生しますが、 nextように別のタグを使用します。

@shousperは、 jq依存関係がない方法です。

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

Foo直接作業しているときに、パッケージFooピア依存関係をインストールしたくないシナリオはありますか？ 思いつかない。 Fooを使用するためにBarが必要な場合、 Fooで作業するときに必要になります。これはピアの依存関係であるため、通常の依存関係にすることはできません。 その場合、パッケージを直接操作する場合にのみインストールする必要があります。これは、開発者の依存関係が行うことです。

そのため、yarnがpeerDependenciesをdevDependenciesと同じように扱うだけでなく、現在行っていること、つまり警告を生成することも理にかなっていると思います。 私は通常、すべてのピアの依存関係をdevdependencyにするだけなので、重複を節約できます。

それを行うことが問題になる理由はありますか？ それはおそらく重大な変更であるため、2.0まで待たなければなりませんが、それ以外は問題ないようです。

1つの問題は、ピア要件よりも具体的なバージョンを開発用にインストールする必要があることです。 その場合、devDependenciesに複製することで、ローカルインストールのピアバージョンをオーバーライドできるはずです。 例えば

peerDepdency：react@^16.0.0
devDependency：react@~16.1.0

reactのローカルインストールを〜16.1.0に制限しますが、ピア依存関係として任意のv16バージョンを許可します。 そのようなものがどこに必要かは完全にはわかりませんが、無効ではないようです。

@bdwainに同意し開発者の依存関係の違いを意味的に理解していますが、実際にはまったく同じ方法でインストールされます。 モジュールの開発中の場合は、開発者とピアの両方の依存関係をインストールする必要があります。モジュールを使用している場合は、リストされている実際の依存関係のみをインストールします。 その場合、 installコマンドで開発者とピアの依存関係の動作が異なるという理由はあまりありません。

@bdwain @kyleholzinger peerDependenciesは、依存関係をインストールする実際のアクションを指示するのではなく、依存関係の必要性を通知することを厳密に意図しているため、同意し

これにより、ルート/トップレベルパッケージにも存在する一時的な依存関係バージョンの問題がサイレントに（そして誤って）使用されないことが保証されます。 例としてbabel-coreを考えてみましょう。

ここでyarnのコンテキストでサポートが不足しているのは、ここで説明するように、ピアと開発部門の両方として定義する機能

とは言うものの、ピア部門のデフォルトのインストール仕様に準拠し、より良い開発エクスペリエンスを提供するために....多分yarnはinstallコマンドに--include-peersオプションを導入する可能性がありますか？

@hulkish私は感情に同意しますが、何かをピアの依存関係として宣言したいが、

特にyarnでの使用法を正しく理解している場合、ピアの依存関係のリストは常にdevの依存関係のサブセットです。 この場合、これは公式に認識されるべきであり、ピアの依存関係を開発者の依存関係として宣言する必要はないと思います。

私がそれを提起する唯一の理由は、開発者とピアの依存関係の両方が一般的に糸の複雑さを増すように感じるので何かを追加するコマンド/オプションを追加すると思う間です、そして私はここのどこかに素晴らしい解決策があるように感じますシンプル😄

@kyleholzinger

@hulkish私は感情に同意しますが、

ユニットテストまたは.buildを実行するために必要ない場合。 私の経験によると、そもそも、両方の場所にそれらを追加する必要があるのはこれだけです。

ここでの解決策は、yarnがピアの自動インストールを可能にするオプションを導入することだと思います。 peerDependenciesを使用する主な利点は、互換性のない一時的な依存関係がいつ使用されているかを把握できることです。 ここで重要なのは、インストール時にピア部門のデフォルトの動作を壊さないことです。

@hulkishは、依存関係の依存関係に依存して、ピアの依存関係の1つをプルするシナリオについて話していたと思います。 ただし、推移的な依存関係は、ピア依存関係で指定された範囲と一致する必要があるため、これによって問題が発生することはないと思います。これは、とにかく広い範囲である必要があります。 推移的な依存関係がピアの依存関係よりも具体的である場合、その範囲が優先され、すべての要件が満たされます。

@hulkish

ユニットテストまたは.buildを実行するために必要ない場合

完全にそれを手に入れよう！ それは疑問を投げかけますが、何かがピア依存関係であるが、単体テストまたはビルドを実行するためにそれを必要としない場合、なぜそれをピア依存関係として持っているのですか？

peerDependenciesを使用する主な利点は、互換性のない一時的な依存関係がいつ使用されているかを把握できることです。

これは私が強く同意します。ピア依存関係を持つライブラリへの依存関係を宣言しているモジュールのコンシューマーから、ピア依存関係は今驚くべきものだと思います。私の主な不満/問題点は、ピア依存関係を持つモジュールで開発するときです。 混乱があったらごめんなさい！

私の主な質問/提案/希望は、それ自体のpackage.jsonピアの依存関係があるモジュールで、 yarn install （本番環境ではない）を取得することです。 package.jsonは、その開発依存関係とそのピア依存関係の両方がインストールされます。 これが主な違いです。現在、インストールされるのは開発依存関係のみであるため、開発依存関係とピア依存関係の両方としてdepsを宣言する必要があります。

@bdwain @hulkish

@hulkishは、依存関係の依存関係に依存してピアの依存関係の1つをプルするシナリオについて話していたと思います

ピア依存関係のあるモジュールを別のプロジェクトに追加するときではなく、ピア依存関係のあるモジュールを開発するときにyarn installを実行するときについて具体的に話します。

@bdwainは正確ではありませんが、説明するのは間違いなく滑りやすいものです。 例を使用してみます：

問題のあるユースケース

これがトップレベルのパッケージだとしましょう。

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

次に、foo / package.json：

  "dependencies": {
    "react": "^16.0.0"
  }

この依存関係ツリーによると、yarn / npm installを実行すると、node_modulesディレクトリは次のようになります。

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

この時点で、（何らかの理由で）node_modulesのネストされたdir構造を自発的に検査することに決めない限り、問題があることはわかりません。 これはパッケージマネージャーのせいではありません-それはその仕事を正確に完了しました。

したがって、peerDependenciesは、インストールの指示ではなく、検証チェックとして扱うことで、このユースケースを解決することを目的としています。

peerDependenciesソリューションのユースケース

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

次に、foo / package.json：

  "peetDependencies": {
    "react": "^16.0.0"
  }

まず、この時点で、両方のユースケースに、 reactバージョンが互いに互換性がないあることを明確にしましょう。

このユースケースの違いは次のとおりです。 この問題の代わりに静かに存在します。 npm / yarn installを実行すると、パッケージマネージャーは非互換性をエラーまたは警告として報告する義務があります。

これがそれをよりよく説明することを願っています。

@kyleholzinger

特に、ピア依存関係のあるモジュールを別のプロジェクトに追加するときではなく、ピア依存関係のあるモジュールを開発するときにyarnインストールを行う場合について話します

わかります。 ピア部門のデフォルトの動作はそのままにしておく必要があると思います。 しかし、簡単な解決策は、これをcliおよび/またはenv変数および/または.yarnrc介して構成できるようにすることだと思います。 --install-peers-as-devようなもの

@hulkish

しかし、簡単な解決策は、これをcliおよび/またはenvvarsおよび/または.yarnrcを介して構成できるようにすることだと思います。 --install-peers-as-devのようなもの

もちろん！ 個人的には、開発者の依存関係とピアの依存関係の両方に含めるべきではないと思いますが、それは別の議論になる可能性があります。 このオプションを追加することは、確実な妥協案であり、当面は問題を解決するための優れた方法になると思います。それをチェックして、何かを一緒に投げようとします:)

@kyleholzingerこれは開始するのに適した場所ですhttps://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

また、peerDependenciesをdevとしてインストールするように転送する際に、互換性の警告やエラーが引き続き報告されるようにすることをお勧めします。

@hulkishピアの依存関係が何であるかを理解しています。 私のポイントは、実際には、開発目的で常にインストールする必要があるため、バージョンが一致しない場合に警告を出す役割に加えて、devDependenciesとして扱う必要があるということでした。

パッケージFooがBarにピア依存している場合、Fooで直接作業するときにBarをインストールしたくない唯一のシナリオは、ビルドと自動テストにBarが必要ない場合です。 しかし、その場合は、ビルド/テストが、そもそもBarへのピア依存を必要とする機能を実行しなかったことを意味します。これは一般的なケースではないはずです。

ピアの依存関係の自動インストールを有効にするオプションは、必要になることが多いため、正しいことではないと思います（ただし、開発の依存関係としてピアを指定した場合は、ポイントが無効になります）。 オプションが頻繁に必要になる場合は、それがデフォルトであり、代わりにそれを無効にするオプションがあるはずです。 yarn installは、最も一般的なケースではオプションなしで機能するはずであり、ピアの依存関係を開発の依存関係として扱う必要があるのが最も一般的なケースです。 平均的なユーザーのために余分なステップを追加することは、ただ悪い経験です。

そして、それらをdevとpeerの両方に自動的に追加することには、依存関係を2つの場所で複製するという問題があります。これは、IMOが問題であり、必要ではないはずです。

いずれにせよ、それらの警告/エラーを報告する必要があります。

この機能がまだない可能性はありますか？ npmパッケージの作成は初めてですが、npmパッケージを開発するコアワークフローの一部のようです。

同じ@biels！ 私は実際にこれに取り組むつもりだと言ったことを完全に忘れていたのでまだ始めていませんが、少なくとも人々にこのオプションを.yarnrc入れてもらうことができるように、できる限りそれに取り組むつもりですいつも心配する必要はありません

この機能は非常に重要だと思います。

特にライブラリの作成者に関しては、多くのユースケースを考えることができます。

reactとreact-domをpeerDependenciesとして持つコンポーネントライブラリを開発したいとします（最終的には、それを使用する人にバンドルされたくないので、重複しますこれらの2つのライブラリは、以前に経験した問題を引き起こす可能性があります）。

peerDependenciesインストールしてコンポーネントライブラリをテストしたいので、CIと自分のマシンでyarn --include-peerDeps （またはそのようなもの）を実行したいのですが、誰かがyarn自分のパッケージに私は彼らが自分の使いたいreactとreact-dom彼らのテストを実行するために、依存関係を（彼らはそれを行う方法は重要ではありません）。

また、これを正確に実行し、ダウンロード数が多いモジュールがあるので、この機能をネイティブにすることはすでに正当化されていると思います。 （「人々が欲しいものを作る」という古いモットーがここIMOに適用されます）

--include-peerDeps明示的に切り替える必要があるため、これがどのように悪い習慣になるかはわかりません。

必要に応じて、実装について話し合い、支援させていただきます。

@lucasfcostaはこれ以上同意できませんでした！ 最近は作業する時間があまりないので、できる限り調べようとしていますが、コマンドラインオプションからオプションを正しく取得できないようです。 しかし、救いの手が大好きです:)

@lucasfcostaこれは、オプションが存在する可能性があると思った場所の私の悪い実装ですがわかりません。 他のいくつかのコマンドラインオプションのパターンに従おうとしていましたが、機能していないようです。

私は現在、複製アプローチ（devDependenciesとpeerDependencies）を採用していますが、この機能が大好きなので、やめることができます。

私もそれが必要です。 その間に私は小さなノードタスクを実行しました

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

涼しい！ これで、それを糸に貼り付けて、旗などを追加することができます。

木、2018年10月4日には、17：29パスクアーレMangialavori [email protected]
書きました：

私もそれが必要です。 その間に私は小さなノードタスクを実行しました

`const pkg = require（ './ package.json'）;
constエントリ= Object.entries（pkg.peerDependencies）;
const shell = require（ 'shelljs'）;

deps = ['yarn add'];
for（[dep、version] of entry）{
deps [deps.length] = $ {dep} @ $ {version};
}

deps.push（ '-peer'）;
const cmd = deps.join（ ''）;
console.log（ 'ピアdepsのインストール！n -----'、cmd）;
const result = shell.exec（cmd）;

if（result.code！== 0）{
shell.echo（ 'エラー：ピア依存関係のインストール'）;
shell.exit（1）;
} `

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
。

@RWOverdijkが言ったように、私も複製アプローチを取っています。 将来的にこの機能を見るのが大好きです。

ところで、1つのパッケージ（devDependenciesとpeerDependencies）を2回追加する必要がないように、誰かがより良いソリューションを持っていますか？

未来からこんにちは。 これは、package / lib開発者にとっては依然として問題です。 重複した担当者が答えになるべきではありません。

この機能を追加してほしいです。 パッケージのdevDependenciesにreactを追加しないと、コードでテストを実行できません。

ローカルのpeerDependenciesオブジェクトにパッケージをインストールするためのフラグがあればいいのですが、_only_ローカルpeerDependenciesデフォルトの動作にすることのマイナス面も見当たりません。 そして意味的には、パッケージが他の場所で機能するためにはピアの依存関係が存在する必要がありますが、なぜローカルで異なるのでしょうか？

旗の使用法についての私の意見は、旗との整合性のために次のようになります
yarn add --peerコマンド。

yarn --peer
# and
yarn install --peer

少なくともフラグを導入する必要があります。

別々のtestアプリを使用することがここで良い解決策であるかどうか疑問に思いますか？ 次に、すべてのpeerDependenciesをtestアプリのdependenciesとして追加できます。 これは次のように思われます。

• ライブラリ内のdevDependenciesからpeerDependencies除外します
• ある意味でライブラリをe2eテストします... distが適切に構築されていること、すべてのコンポーネントを正しくエクスポートしていること、およびそのようなことを確認します。
• "my-package": "file:/path/to/my-package"などのローカル依存関係を使用しているときに、パッケージからnode_modulesをクリアするのを忘れた場合に、発生するInvalid hook callエラーを回避します

より多くの情報が人々に役立つ場合は、このアプローチをモデル化して問題を文書化するために、デモリポジトリを作成しました。
https://github.com/jamstooks/package-peer-dependencies

今のところ、 npx install-peerdeps <package>を実行できるはずです。その後、フォルダにヤーンロックなどがある場合、CLIはインストールにヤーンを使用するかどうかを尋ねます。 少なくとも今はそれでうまくいきました。

このNPMRFCで、Arcanis（「欠落しているピアdepsのインストールに失敗する」）とIsaac（「ピアdepsを自動的にインストールする」）からの詳細な説明：

https://github.com/npm/rfcs/pull/43

このブログ投稿は、この問題を解決するのに役立ちました： https ：

関連する問題があると思います。
最小限の再現のために、私は依存関係のこのリストを持っています：

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

説明：私のパッケージは、実行時にreact存在に依存しており、テストにも必要です。 reduxはデモ用です。以下を参照してください。

現在、 prismic-reactjsもピアの依存関係としてreact依存しています。
yarn --productionが呼び出された後はどうなりますか？

Reactは_installed_と_hoisted_の両方です
私は2つの_none_が起こることを期待します。

デモの目的で、ここにreduxが追加されていますが、これはインストールされていません。これは、一時的なピアの依存関係が問題の原因であることを証明しています。

Reproリポジトリ： https ： 。 クイックチェックのためにtest.shを実行します。

npmはv7でこの機能を備えています...これをyarnに追加しない理由はありますか？

@sajadghawami私の知る限り、 @ arcanisには、これを行うことに関してかなり大きな予約があります。

https://github.com/npm/rfcs/pull/43#issuecomment -520584797