<p>ヤーンはおそらくファイルパスで解決されたパッケージをキャッシュすべきではありません</p>

これも私をだましました。 すべてのキャッシュをクリアせずにこれを回避する方法が必要です。

この場合、糸を使用できるようにする方法は3つあると思います。

1. @donaldpipowitchによる、すべてのローカル依存関係を無視するという提案。
2. キャッシュされたときよりも後でファイルが変更された場合に、ローカルの依存関係を再インストールします。 これには、このメタデータを保持する必要があります。 ローカル依存関係の場合、「解決済み」列に次のような行を挿入できます： file://<path>@<cache_timestamp>
3. yarn cache rm <package>やyarn cache add <package>などのコマンドを使用して、パッケージ名でパッケージを無視します。 すべての依存関係。

2番目の提案が実装されることを望んでいます。 そうでない限り、3番目のオプションは他の場合にも役立つ可能性があります。 たとえば、 yarn cache add <package>を使用して、依存関係のダウンロード中に問題が発生した場合に備えて、すでにキャッシュされている依存関係のキャッシュを更新できます。

@hantuzunなぜローカル依存関係をキャッシュするのですか？ それらはとにかくローカルなので、キャッシュされているかどうかに関係なく高速になります。

@ satya164その通りです。 ただし、ネットワークからの依存関係を意図的に変更した場合は、3番目のアプローチが役立つ傾向があります。

yarn cache ignore <package>ようなものが役に立ちます。 しかし、それらは相互に排他的である必要はないと思います。 パッケージを無視することは便利ですが、手作業が必要です。 ファイルの依存関係は、デフォルトで無視されていれば、追加の作業なしで機能させることができます。

誰かが私に内部ロジックを説明できますか？

私の理解：
file:依存関係が検出されると、 file-resolver.js起動します。依存関係をコピーする必要があり、ハッシュされないことを示しています。 ハッシュがないということは、それがまだキャッシュされるべきではないという意味ではありませんか...？ しかし、 copy-fetcher.jsは、 nullを保持する代わりに、ハッシュを空の文字列に設定しているようです...これは問題ですか？

@bestanderまたは@kittens多分あなたはこれをもう少し説明することができます...？ PRを作成するために少し助けを得たいです♥

ハッシュとは、たとえばtarball-fetcherに使用されるmd5ハッシュを意味します。
このハッシュは、将来の検証のためにyarn.lockファイルに追加され、解凍されたフォルダーをキャッシュに保存するときにフォルダー名にも追加されます。
あなたは正しい方向に掘っています、これを調べてくれてありがとう、PRは大歓迎です。
あなたはおそらく壊れたユニットテストを追加するPRから始めることができます

あなたはおそらく壊れたユニットテストを追加するPRから始めることができます

さて、あなたの応答に感謝します。 PRのレビュー担当者としてあなたにpingを送信する必要がありますか、それとも他の誰か（または誰も）にpingを送信する必要があります...？

ええ、私にpingします

@bestanderおそらくこの問題はまだ修正されていないので、閉じるべきではありませんか？

はい、再度開く必要があります。 PRのタイトルに「fixes＃2165」と書いたので閉店しました。 最初は継続的なPRになると思っていましたが、このバグを修正するには、2つのPRが必要です。最初のPRは単体テストを追加し（失敗するアサーションは実際にはアクティブではないため、CIは爆発しません）、 2番目のものは実際にそれを修正します。

申し訳ありませんが、PRがマージされるとgithubは問題を閉じます

明らかにこれはまだ問題ですか？ 正直に言うと、一緒に開発するのはかなり面倒です。 それは私が仕事で個人レベルで少し混乱を引き起こしています。そこでは私はfile:を利用してモジュラー開発環境を作成しています。 厄介なのは、（ package.jsonのfile:パスを使用して）編集するすべてのローカルパッケージで、更新されたコンテンツをプルダウンするためにこれを行う必要があることです。

eslint-config-base-eslintパッケージの内容を編集する

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

どなたでもプロジェクトに貢献できます。
それは何でもかまいません-この場合の壊れた統合テスト、修正を提出するか、誰かに修正に取り組むように説得します。
それにアプローチするための最良の方法についてチャットしたい場合は、discordチャンネルでヘルプを見つけることができます。

実際、修正は10〜15行のコードである必要があると思います。おそらく、より早く修正することで多くの時間を節約できます。

参考：この問題は、遅いlinking dependenciesステップにも関連している可能性があります。 ここで私のコメントを参照してください： https ：//github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818。

ごめんなさい。 私はこの問題のために別のPRを作成する時間を見つけることができませんでした:(私は（そしてまだ）とても忙しかったです。

@bestanderこれは私にとってかなり大きなブロッカーであり、マルチモジュールプロジェクトに取り組んでいます。 @donaldpipowitchのコードリンクとコメントを正しく読んでいる場合、ファイルリゾルバーが解決しようとするたびに（nullではなく）新しいhash作成して、再インストールを強制することができますか？ UUIDまたは現在のタイムスタンプを言いますか？ 何かが足りない場合はご容赦ください。コードの動作方法に慣れていません。

タイムスタンプとuuidを備えた新しいキャッシュは、合理的なハックのように聞こえます。
理想的には、キャッシュなしでファイルを直接コピーする必要がありますが、
より複雑な変更。
PRを送ってください

午前3時38時火曜、2017年3月7日には、マットTraynhamの[email protected]は書きました：

@bestanderhttps ：//github.com/bestanderこれはかなり大きなブロッカーです
私にとっては、マルチモジュールプロジェクトに取り組んでいます。 @donaldpipowitchを読んでいる場合
https://github.com/donaldpipowitchのコードリンクとコメント
正しく、ファイルリゾルバーに（代わりに）新しいハッシュを作成させることができますか？
null）解決しようとするたびに、再インストールを強制しますか？ UUIDを言う
または現在のタイムスタンプ？ 何かが足りない場合は許してください、私はなじみがありません
コードが機能する方法で。

—
あなたが言及されたのであなたはこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/yarnpkg/yarn/issues/2165#issuecomment-284612526 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
。

@bestander最後のコメントについて：ファイルをコピーする代わりに、シンボリックリンクする方が理にかなっていますか？ それともそれをしない理由はありますか？

@danrot Windowsでは、管理者がシンボリックリンクする必要があるようです。
また、ノードモジュールを見つけるために再帰的に混乱します

シンボリックリンクも.npmignoreなどを無視します。 （これも現在無視されているようです。問題が発生する可能性があります：https：//github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818）

現在、キャッシュ全体のクリアを禁止している回避策はありますか？ 残念ながら、 yarn cache rm packageようなコマンドはないようです。

@ rhys-e私はこの小さなスクリプトを使用します：

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

誰もがちょうどしようとしていますyarn link上のすべてのローカルの依存関係postinstall ？ 適切な修正が行われるまで、適切な解決策のように見えます。

ローカル依存関係の変更のたびにパッケージのバージョン番号を更新する必要がないという考えだと思います。 糸のリンクはあなたにそれを強制するでしょうね？ （試しませんでした）

私の側では、最終的に行ったのは、インストール前のフェーズでスクリプトを呼び出して、ローカルの依存関係についてソースフォルダーとnode_modulesフォルダーにあるものを比較することです。 違いを検出すると、キャッシュされた依存関係を削除し、整合性ファイルを削除します（再インストールを強制するため）。 したがって、変更がない場合、yarnのインストールは非常に高速であり（ローカル依存関係は多くありません）、古いキャッシュバージョンがある場合は使用されません。

@lucdew linkは基本的に

./node_modules/の下にある親プロジェクトのインストール済みバージョンで更新されないローカルパッケージの変更を回避するために、さまざまな組み合わせをテストしました。 ./node_modules/を削除しなくても、これで十分だと思います。最初：

yarn cache clean; yarn upgrade file:../<package>

言うまでもなく、ローカルパッケージを更新/アップグレードするために、手動でグローバルキャッシュのクリーンアップを強制する必要はありません。

@fungilation回避策として、npmを使用してローカルの依存関係をインストールし、更新が必要になるたびにキャッシュ全体が失われるのを防ぐこともできます。

＃2860とそれに続くマージコミットhttps://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24に従って、 file:プロトコルの依存関係を「更新」できるようになりました。

yarn install --force

特定のパッケージを編集またはアップグレードします（これも機能することに気づいていませんでした）。 依存関係のバージョンが変更されていない場合、ロックファイルは変更されませんが、新しいバージョンがコピーされます。

yarn upgrade [file protocol package name]

PRの変更により、キャッシュ内の依存関係が無効になり、ローカルに再インストールされます。 yarn installは、依存関係のバージョンが変更された場合にも機能し、yarn.lockファイルが無効になります。 キャッシュをクリアしたり、ローカルインストールからモジュールを削除したりする必要がなくなりました。

また、おそらくlink:プロトコルを使用して、依存関係をリンクするためのアクティブなRFCがあることも明らかになりました。 これは、 https：//github.com/yarnpkg/rfcs/pull/34でフォローでき

@mtraynhamプルリクエストありがとうございます！ 👌これは素晴らしいです。 --forceが必要な理由は何ですか？ 私は現在、それを調べずに正確に何をしているのかさえ知りません：）npmは--forceフラグを必要とせず、npmのように振る舞うのが良かったので、ただ尋ねてください。

編集yarn upgrade [dependency]機能するようです。 指摘したいのですが、これは常にロックファイルを変更するわけではなく、package.jsonのバージョン変更のみを反映する必要があります。 アップグレードの方がおそらく適切なので、元の投稿を更新しました。

短いバージョンでは、ロックファイルが変更されていない場合、Yarnはキャッシュリゾルバーに対して何も実行しないため、ロックファイルのチェックをスキップして、新しいバージョンがあるかどうかをキャッシュに確認する必要があります。 これは、 upgradeまたはinstall --forceを使用して実行できます。

yarn install --forceドキュメントごと

「以前にインストールされたものも含め、すべてのパッケージを再フェッチします」。

これは、実際には、ロックファイルの整合性チェックをスキップすることを意味します。 package.jsonファイルを変更せず、正常にベイルアウトすると、通常、ロックファイルの整合性チェックに合格します。 それをスキップすると、キャッシュにロックファイルに対する依存関係の欠落/不一致をチェックし、欠落している場合はダウンロードして、新しい/欠落している依存関係をローカルにコピーして戻すように要求します。 次に、npm install / postInstallスクリプトを実行します。

PRの変更により、キャッシュ内のfile:依存関係が無効になり、新しいバージョンがローカルにコピーされます。 これ以前は、 file:依存関係が無効になることはありませんでした。 他のプロトコルの場合、package.jsonファイルを変更しなかった場合、それらは変更されません（キャッシュ内およびローカル内）。

では、これは私たちにとって何を意味するのでしょうか？ プロジェクトには約60の依存関係（AngularからWebpackまで）があり、1つのfile:依存関係があります。 ローカル依存関係のみを更新したい2番目のinstall --forceでは、約5秒かかります（ yarn install約1.5秒から増加）。 私にとって、これはごくわずかであり、実際には、プロセス全体を通して作業糸がほとんど実行されないことに非常に感銘を受けています。

ロックファイルのチェックをスキップして、特定のファイルの依存関係のみについてキャッシュをチェックする別のCLIコマンドがある場合、それはおそらくさらに高速ですが、私はそれを見つけていません。

そうは言っても、私はこれをバンドエイドと呼んでいます。 これは、 link:などのより良いソリューションに置き換えることができます。 ローカルの依存関係をキャッシュすることを本当に気にかけている人はいないと思います。 少なくとも、 install --forceまたはupgradeを使用することによる追加のオーバーヘッドはほとんど無視され、 yarn cache clean; mv node_modules /tmp/を使用する必要はありません。

素晴らしい答え。 👏これを書き留めていただきありがとうございます。

ヤーンはローカルのシンボリックリンクされたプロジェクトファイルをヤーンのキャッシュからのファイルで上書きしますか？ （それが起こっているように見えるので）

PRの変更により、ファイルが無効になります。キャッシュ内の依存関係が無効になり、新しいバージョンがローカルにコピーされます。

これは、依存関係として"foo": "file:../"を持つパッケージ内で$ yarnを呼び出すたびに、 "file:../"新しいコピーが作成されることを意味しますか？

たとえば、パッケージでもある複数の例を含むパッケージがあります。

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

そして、私は今、糸のキャッシュにfoo 10回持っているようです。 また、 fooバージョン変更ごとに例をテストしているので（ fooだけでなく、複数のモジュールがそのように構成されています）、現在、yarnキャッシュが_本当に_急速に増加しているように見えます。

これは正しい動作ですか？

キャッシュに古いバージョンがあるよりも良い選択肢だと思います。
ヤーン0.26では、ファイルをコピーする代わりに、 link:を使用してシンボリックリンクを作成できます。
また、シンボリックリンクの作成を自動化するワークスペース（ https://github.com/yarnpkg/yarn/issues/3294）にも取り組んでいます

ええ、ワークペースを楽しみにしています👍

link:はまだnpmでは機能しませんよね？ （https://github.com/npm/npm/pull/15900はまだ開いているためです。）

npm 5パッチノートから、ファイルはfile:構文で自動的にシンボリックリンクされるようになりました。

npm install ./packages/subdirは、通常のインストールの代わりにシンボリックリンクを作成するようになりました。 file：//path/to/tarball.tgzは変更されません–ディレクトリのみがシンボリックリンクされます。 （＃15900）

そうそう、npmにはlinkはありません。

npm install ./packages/subdirは、通常のインストールの代わりにシンボリックリンクを作成するようになりました

ちょっと残念です。 すべて（ node_modulesを含む）をコピーし、 .npmignoreまたはfilesフィールドを尊重しないため、ファイル部門が同じように動作することはありませんでした。 今ではシンボリックリンクでさらに悪化しています。

file：とlink：はさらに改善される可能性があると思います。独自の長所と短所を持つさまざまな戦略があり、Yarnではユーザーが1つを選択できるようにする必要があります。
たとえば、 knit RFCは、戦略の1つとして実装できますhttps://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

キャッシュに古いバージョンがあるよりも良い選択肢だと思います。

または、ディスクスペースが不足して、Yarnキャッシュが何百万ものまったく役に立たないファイルに数十ギガバイトを使用していることがわかるまでは信じられないでしょう。
開発システムを一時的に壊したことが一度だけわかるので、全体を以前よりも深刻に壊すIMO。

こんにちはみんな、この問題に関する最新情報はありますか？ これは私たちにとって本当に大きな問題です。特に、同じリンクされた複数の依存関係に依存する複数の製品に同時に取り組んでいる場合はなおさらです。 開発の1日でギガバイトのキャッシュなど。少なくともオプションにして、そのようなパッケージのキャッシュを無効にできますか？

@nikdojo依存関係にはfile:代わりにyarn link:プロトコルを使用し、シンボリックリンクを使用します。 0.26で

または、プロジェクト間の依存関係が多い場合は、ワークスペースの使用を開始し

@mtraynham Thxのヒントとして、公式ドキュメントでlink:プロトコルに関する情報を見つけようとしましたが、そこにはないようです。 今ワークスペースで実験しています。

@bestanderところで、ご存知のように、react-nativeはシンボリックリンクをサポートしていないため、rn libsを使用する場合、それは依然として大きな問題です。

これは決して解決されませんでしたか？ リンクローカル（NPMパッケージ）を使用してローカルパッケージをリンクする必要があります（これは、ローカルファイルシステムからパッケージを消費するときにyarnが動作する標準的な方法です-キャッシュの代わりにWindowsでジャンクションまたはシンボリックリンクを使用します）。 次に、新しいyarn installがキャッシュからの古いものですべてを上書きし、リンクを最初からやり直す必要があります。

アーキテクチャの宇宙飛行士を減らして、ローカルパッケージをキャッシュしないことはできますか？ この問題は現在1。5年前のものであり、 another-local-package何かを変更するたびにyarn add ../<another-local-package>を実行するのにうんざりしています。

こんにちは@fungilation
私は別の関連する問題を開きました：＃6037

動作しません
App.jsファイルに入れました
console.log（ 'here we are'）であり、出力されませんでした。
次に、すべてのファイルを削除しても、キャッシュから出力が作成されます。
これを回避する方法は？

毛糸はこの問題で私を本当に失敗させました。 これを除いて、それは他のすべてにとって素晴らしいことでした。

テスト目的でローカルパッケージの新しいバージョンをインストールしようとしていますが、何をしても古いパッケージになってしまいます。

私はもう試した：

1. ヤーンキャッシュのクリーニング（ yarn cache clean package-name ）
2. yarn add 'ing with --force
3. node_modules/package-nameとyarn add再度削除します
4. ローカルパッケージのバージョン番号とファイル名を更新します（ yarnは、新しいが、古いバージョンのコンテンツをインストールします）
5. 上記のすべての組み合わせ

これはばかげています、そして私はこれに私の一日のほぼ4時間を費やしました。

ローカルパッケージを開発して再インストールする機能が必要です。 .binフォルダーにファイルをインストールするのにyarnに依存しているので、 yarn linkは問題外です。

@ Yarn Developers：ローカルパッケージをインストールし、そのローカルパッケージに変更を加えてから、再度インストールすることで変更を反映させることができますか？

@gregjacobs yarn install --force成功しました

@jonathantorley --forceでもう一度試してみましたが、 yarn1.12.3ではまだ機能しません

この問題に直面している他の人のために：私が実際にこれを機能させるために使用した1つの回避策は、依存パッケージのバージョン番号を増やすことでした。 少し面倒で、変更のたびにそれを行うことを忘れないでください（スクリプトを作成できない場合）。

yarnは、ローカルパッケージをインストールするときに、この回避策を絶対に必要としないはずです。

preinstallスクリプトにyarn upgrade MY_PACKAGE_NAMEを追加しましたが、最新のNPMバージョンにうまくアップグレードされます。 （それでも、NPMバージョンを手動でバンプする必要があります）。

yarn add file:PATHは、常に新しいコンテンツをyarn1.13.0でアップグレードしているようです。
yarn installまだありません。

@leavessterそれでも私には向いていません。

更新するには、tgzの名前を変更する必要があります

linkコマンドを使用してみてください： https ：

yarn add file:PATHは私のために新しいコンテンツをアップグレードしませんでした。 さらに、package.jsonおよび.npmignore内のファイルは尊重されません。

パッケージのバージョンを変更することで機能します。

yarn add file:PATHでpackage.jsonと.npmignoreのファイルを尊重する場合は、ローカルパッケージの依存関係でyarn packを実行してから、インストールする場所でyarn add file:path-to-local-pacckage.tgz実行する必要があります。

linkコマンドを使用してみてください： https ：

yarn linkは、同じ問題に答えることを目的としたものではありません。 package.jsonと.npmignoreのファイルを尊重して公開された場合のように、誰かがnpmパッケージを必要とする場合は良くありません。

@leavessterそれでも私には向いていません。

更新するには、tgzの名前を変更する必要があります

パッケージにtgzがなく、 yarn add file: PACKAGE_PAHを使用して現在のプロジェクトに追加しています。 パッケージにjsコードが含まれています。 多分tgzはまだ間違っていますか？

私のためにも働いていない

@bestanderなぜこの問題は解決したのですか？ Yarnはまだローカルファイルとtgzパッケージをキャッシュしています。 ワークスペースが解決策にならない場合があります。たとえば、あるパッケージに特定のバージョンのdepsがあり、他のパッケージに最初のパッケージと同じパッケージで別のバージョンのdevDepsがあり、あるパッケージを別のパッケージにリンクすると、プロジェクトが壊れている場合があります。 。

@gregjacobsと同じ問題があります。 yarn cache clean packageは役に立ちませんでした。 しかし、 yarn add path/to/package.tgzをインストールしてからアーカイブを別のアーカイブに置き換えると、新しいバージョンをインストールできるので、 yarn add path/to/../to/package.tgzようにパスを変更するだけで、絶対パスは同じですが、ヤーンの場合は異なります。 。

yarn cache list --pattern packageが空であっても、yarnがキャッシュされたパッケージを解決パスでどこに保存するのかわかりません。

問題はここのどこかにあると思いますhttps://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58-L63

何が起こっていますか：

• URLからpath/to/package.tgzはハッシュを生成します（そのため、 path/to/package.tgzとpath/to/../to/package.tgz結果は異なるハッシュになります）
• そのハッシュを使用して、パッケージの一時ディレクトリを作成します（このような/Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 ）
• 最初の実行ではisValidModuleDest falseを返し、すべてがうまくいきます
• このディレクトリに抽出されたTarballパッケージ
• プロジェクトにインストールされたそのディレクトリのファイル
• 開発プロジェクトソースを変更し、前のものと同じ名前と場所で新しいパッケージtarballをビルド/パックします
• そして、新しいtarballをインストールしようとしましたが、生成されたハッシュは以前と同じであり、最初の実行後に一時ディレクトリがクリアされませんでした
• したがって、今回はisValidModuleDestがtrue返します
• そして、あなたのパッケージの古いバージョンをヤーンインストールします
• yarn cache clean package実行しますが、一時ディレクトリは変更されません。

@bestanderここで一時ディレクトリを削除できますか

同じ問題に直面して、ローカルパッケージで1日だけ作業した後、一時フォルダーの下のキャッシュに10GBかかります。

この問題を再開できますか？ 私たちは同じ問題に直面しています。 ファイルを介して別のパッケージを参照する2つのプロジェクト：。 CI / CDサーバーでいくつかのビルドを行った後、キャッシュフォルダーが多くのスペースを占有し始めています。

リンクプロトコルがこれに対する最善の修正だと思います。file：//はまだ手動でキャッシュをクリーンアップして強制的にインストールする必要があるため、機能しません。

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

依存関係を次のようにするだけです

"<package>": "link:./libs/<package>"

@alxtzリンクプロトコルはtgzのパッケージで機能しますか？

リンクプロトコルがこれに対する最善の修正だと思います。file：//はまだ手動でキャッシュをクリーンアップして強制的にインストールする必要があるため、機能しません。

＃2165（コメント）

依存関係を次のようにするだけです

"<package>": "link:./libs/<package>"

これに感謝します。これは、 node_modules内のfile:..参照をシンボリックリンクするNPMの動作を複製します。 文書化されていないようですが、少なくともここでは、 https ：

残念ながら、 linkはすべての場合に使用できるわけではありません。

たとえば、SDKパッケージからの共有/ピア依存関係が必要です。これを変更すると、ローカル開発作業にリンクします。
link 、yarnは依存関係が共有/ピア依存関係であることを認識せず、シンボリックリンクがあるローカルパッケージを使用しますが、これは正しくありません。

私が使用してきたyarn packと一緒にyarn add file:<path_to_packed_tgz>この問題を回避します。
@wKichの素晴らしい発見によると、同じハッシュを生成しないように、パッケージをパックしてリポジトリに貼り付けるたびにパッケージの名前を変更し続けることができますが、それは

yarn add file:<path>を使用して指定されている場合、yarnがローカルの.tgzパッケージをキャッシュからロードしないように、リポジトリをフォークしてifステートメントに追加の句を追加しました。

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

人々が望むなら私はPRをすることができますが、私はこれまでにそれをしたことがなく、それはかなりハッキーな修正です。
このアプローチが引き続きローカルパッケージをyarnのキャッシュに追加するかどうかを誰かが確認できますか？

@ojbojの場合、これが適切に修正されるまで、 yalcが役立つ可能性があります。 公開する前にローカルでパッケージをテストすることは、私にとって非常にうまく機能しています。

@souporseriousそれはまさに私が必要/望んでいたことです、どうもありがとうございました！

非常識なこれは、何年も経った今でも問題です。

それは[email protected]で修正されて

@wKich私はそう信じています！ 個人的にテストしたことはありませんが、新しいポータルプロトコルを通じてローカル開発を解決しているよう

link:プロトコルを使用しても「同じ宛先で解凍」エラーが発生し、キャッシュディレクトリを参照しているため、yarnはまだlink:依存関係をキャッシュしているようです。 同じローカルパッケージの2つのコピーを参照しており、それを使用する各アプリの.deps/フォルダーにコピーされています-以下のエラーのfront-endとrenderer 。 （関係のない理由でオリジナルにリンクできません）

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.