@chinesedfan yarn upgrade-interactiveを試しましたか？

@milesjはい、同じ結果になります。また、問題の説明の再現手順も更新しました。

これは、 yarn add [email protected]がpackage.jsonを要求どおりに_exactly_バージョン1.0.0に設定するためです。

yarn upgradeはpackage.json semverの範囲を尊重し、バージョン1.0.0を正確に指定したため、他のバージョンへのアップグレードは提供されません。

これはいくつかの方法で解決できます。

• yarn upgrade --latestは、semver範囲を無視し、レジストリでlatestとしてタグ付けされているものを確認します。
• package.jsonを変更して、 ^1.0.0 、次にyarn upgradeのようなバージョン範囲を受け入れます（変更された範囲のロックファイルを更新するには、最初にyarn installを取得する必要がある場合があります）
• yarn upgrade [email protected]やyarn upgrade is-alphanumerical@^1.0.0のように、バージョンをupgradeに明示的に指定します

編集：

申し訳ありませんが、パッケージ名が異なることに気づきました。 alphanumericalとalphabeticalは一見同じように見えます:)

そうです、 is-alphanumericalのアップグレードがないため、依存関係ツリーは、推移的な依存関係を処理するために、これ以上深くトラバースされることはありません。

--forceフラグを追加してみて、それがサブ依存関係になるかどうかを確認できます。 そうでなければ、あなたは正しいと思います。 yarn remove is-alphanumericalとyarn add is-alphanumerical以外にそれを行う簡単な方法はありません。

@ rally25rsお返事ありがとうございます！ さらに2つのケースをテストしました。

• yarn upgrade is-alphabetical --forceも機能しません。
• yarn upgrade is-alphanumericalは、すでに最新である場合でも、すべてのサブ依存関係をアップグレードします。
  
  
  
  • しかし、指定されたサブ依存関係をアップグレードしたいだけの場合、それでもあまり便利ではありません。
  
  

はい、これは現時点での糸の大きな問題です。 すでに＃2394で議論されています

重複＃2394

もう一度開いてください。重複していません。

2394は、 meck-test-bbパッケージの複製について説明しています（間接的な依存関係）。

meck-test-bbを2つ入手しました

この問題は、（どういうわけか）間接的な依存関係をアップグレードする機能についてのみ説明しています。

@rally25rspingを許可してください。

@ rally25rs 、お願いします、あなたは両方の重複しない問題を閉じました、それは間違っています。 間接的な依存関係をアップグレードする機能を提供してください。

申し訳ありませんが、他の問題について混乱がありました。 私は当初、2394が--deepフラグなどを使用して推移的なdepをアップグレードする方法を求めていると思っていたので、この問題をその重複としてマークしました。 後で2394を読み直した後、それは私が最初に考えたようなこれの複製ではない、何か違うことについてだったと思います。

この機能リクエストの+1。 また、暫定的に特定の間接的な依存関係を手動でアップグレードする必要がある私のような愚かな人の例：

明示的な依存関係が与えられた場合jsonwebtokenは脆弱なjws=3.1.4 $への暗黙的な依存関係jws^3.0.0を解決しました：代わりにパッチを適用し3.1.5に解決する必要があります：

以下のjwsエントリをyarn.lockから削除し、 yarnを再実行します。 間接的な依存関係と影響を受けるパッケージは、他のものに触れることなく更新されます（少なくともyarn v1.3では）

jws@^3.0.0, jws@^3.1.4:
  version "3.1.4"
  resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2"
  dependencies:
    base64url "^2.0.0"
    jwa "^1.1.4"
    safe-buffer "^5.0.1"

編集：句読点

@ alex-thewsey-ibm、回避策をありがとう！

ヤーンv1.7に取り組んだ。

ty、働いた糸1.9.2

単一の依存関係の場合でも、選択的な依存関係resolutionsでヤーンを微調整するのに役立つ場合があります。 ヒントをくれた@remolueoendに感謝します！
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

ドキュメントから：

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }
}

yarn.lock https://github.com/postcss/autoprefixer/issues/1184でcaniuse-liteを更新する方法をユーザーに提案するには、Autoprefixerにこの機能が必要です。

ここでも同じ問題があります。 私はyarn upgrade caniuse-lite browserslistがサブ依存関係をアップグレードすることを期待していました。 それはそれをしませんでした、そしてそれはそれが依存関係ではないのでそれをアップグレードすることができないというエラーメッセージを私に与えませんでした。

関連するロックファイルエントリを削除してから、@ alex-thewsey-ibmが提案したようにyarnを再実行すると、当面の問題が修正されました。

糸にtnis機能がないのは奇妙です。 私はyarn（およびnpm）に慣れていないので、これを行う方法があるはずだと思います。 このスレッドの誰も知らない、これを行うための非自明な方法があるのか​​、それとも実際にこれを行う方法がないのか、私はまだ完全にはわかりません。

package.jsonに追加せずにロックファイル内の他動詞/間接依存関係をアップグレードする方法が本当にない場合...yarnユーザーがそれなしでどのように行うかわかりません。

これは予期しない動作のIMOです。最近lodashをyarn upgrade [email protected]で更新しようとしましたが、一時的な依存関係についてはまだ更新されていません。

私はまだすべてのmajor （^ 4.XX）とpatch （〜4.17.X）のバージョンが古いバージョンを指しているままでした。

これを修正する唯一の方法は、 yarn.lockを手動で編集してから、 yarn upgradeを実行して変更を統合することです。 このように広く使われているツールには、もう少し良いものが期待できます。

この認められたバグまたはヤーンはデフォルトで保守的であり、手動でyarn.lockを編集するか、フラグを使用する必要がありますか？

@Machiawelicznyと同じセキュリティアラートを解決する必要があると思います;）プロジェクトが修正するのを待つ間、間接的な依存関係をオーバーライドすると非常に便利です。 応答性の高いプロジェクトでも、修正とリリースを待つのに遅れがあります。

実際、これは間接的な依存関係のセキュリティ問題にとって問題であり、 yarn.lockを編集する回避策は効果的ですが、期待外れで自動化が困難です。 これが何らかの理由でデフォルトの動作ではない場合は、Yarnに間接的な依存関係に従うように強制する--include-indirectのようなオプションを追加すると便利です。

オプションが必要だとは思わないyarn upgrade [an indirect dependency]がyarn.lockを依存関係ツリーで許可されている最新バージョンの間接依存関係に更新しない理由がわからない。追加オプション。 私は今それはただのノーオペレーションだと思いますか？

ただし、私が満足している別の回避策は、package.jsonにresolutionsを追加することです。 lodashが間接的な依存関係であり、セキュリティの脆弱性を回避するために4.7.13以上である必要があることがわかっている場合は、package.jsonに追加できます。

  "resolutions": {
    "lodash": ">= 4.17.13"
  }

次に、 yarn installを実行するだけで、その要件を満たすようにyarn.lockが更新されるか、間接的な依存関係と競合するためにできない場合は文句を言います。

私の場合、これは実際にはかなりうまくいったようです。 それは「回避策」ではなく、意図された解決策ではないかと思いますか？ しかし、発見するのに少し時間がかかりました。 そして、これが普遍的で正しい解決策であるかどうか、または場合によっては問題があるかもしれないかどうかを確認するのに十分なことを理解していません。 それが間接的な依存関係をアップグレードするための「正しい」解決策である場合、見つけるのはやや困難でした。

更新したい推移的なdepをyarnインストールして、package.jsonの変更をコミットせず、yarn.lockだけをコミットしてみませんか？

更新したい推移的なdepをyarnインストールして、package.jsonの変更をコミットせず、yarn.lockだけをコミットしてみませんか？

単一のバージョンが関連するすべてのsemver範囲を満たしている場合でも、yarnは同じパッケージの複数のバージョンを喜んでインストールするため、（常に？）それが機能するとは思いません。 したがって、これにより必要なバージョンがインストールされますが、不要なバージョンは削除されません。

@djmitcheそうですね。 予想される範囲内のバージョンをインストールする必要があります。 理想的ではなく、少し退屈ですが、今のところ利用可能な一時的なギャップです。

@djmitche確かに、これは間接的な依存関係のセキュリティ問題にとって問題であり、 yarn.lockを編集する回避策は効果的ですが、期待外れで自動化が困難です。

これは、もう少し自動化可能な別の回避策です。

yarn remove is-alphanumerical
yarn add is-alphanumerical

PRの説明の例を使用すると、これにより最上位のdepが削除されてから再度追加され、 is-alphanumerical指定された範囲（キャレット範囲など）に従って、最新のサブdepsがすべて取得されます。 。 その後、新しいロックファイルが生成されます。

副作用は、理想的ではないすべてのサブディープを更新することです。 sub-dep Aのセキュリティ問題については、sub-depAのみを更新したいと思います。

セキュリティの問題を修正するためだけにサブデップAを直接デップとして追加する回避策は、混乱（パッケージが直接使用されない）とメンテナンスの負担を引き起こすため、さらに悪化します。

毛糸除去は-アルファベット順
糸の追加は-アルファベット順

これは、依存関係を実際に更新する唯一の信頼できる方法のようです。 私は今日、1年前に1.1.0に更新されたパッケージの1.0.0バージョンで立ち往生していることに気づきました。 私たちが使用していたパッケージは^1.0.0を使用し、そのパッケージを「アップグレード」するたびに、依存関係の新しい1.1.0バージョンを取得することはありませんでした。
この問題が発生した理由を調査するために1日を無駄にすることなく、1年前に修正されるべきであった、製品に黙って失敗していたかなり悪いバグがあったことが判明しました。

手動でyarn.lockを編集したり、パッケージを削除してから再追加したり、選択的な解像度を使用したりすることが、間接的な依存関係を更新する「方法」であるとは信じられません。

IMO、 yarn upgradeは、間接的な依存関係を最新の受け入れられたsemverバージョンに更新する必要があります。そのため、パッケージをアップグレードします。 つまり、semverの範囲にブレークがあった場合、間接的な依存関係が更新されるため、常に更新する必要があります。

これを行うために、ある種の外部スクリプトを作成することは役に立ちますか？ 指定されたパッケージのすべてのyarn.lockエントリを削除してから、yarnを再実行すると思いますか？

これを行うための簡単なスクリプトがあります： https ：//gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

メンテナの1人がラベルをcat-featureからcat-bugに変更できますか？

メンテナの1人がラベルをcat-featureからcat-bugに変更できますか？

なぜ？ これはバグではありません。 設計通りです。 yarn upgradeは、推移的な依存関係をアップグレードするために使用されることを意図したものではありませんでした。 最初に開かれた「問題」は、機能要求としてもラベル付けされます。

内部的upgradeはyarn outdatedを使用して、何が古く、どのバージョンにアップグレードするかを決定します。 outdatedは、直接の依存関係のみをチェックします。

私は間違っているか、おそらく変更されている可能性がありますが、少なくとも3年前にyarn upgradeが最後に作り直された時点では、 npm upgradeも推移的な部門をアップグレードします。 （繰り返しになりますが、それは何年にもわたって変更されている可能性がありますが、npmの変更についてはあまり最新ではありません）。

この機能を追加するには、誰でも自由にPRを送信できます。 これはオープンソースプロジェクトであり、貢献するのはコミュニティ全体の責任です。 この機能リクエストは何年にもわたって開かれていますが、誰もそれを実装するためにステップアップしておらず、それが「修正」されていない理由です。

@nnmrts私のスクリプトを確認していただけますかhttps://github.com/yarnpkg/yarn/issues/4986#issuecomment-562719589今のところ役に立ちますか？

@ rally25rs申し訳ありませんが、私は疲れていて不機嫌でした。私のコメントは解決したと考えてください。 😬

@nnmrts私のスクリプト＃4986（コメント）を確認していただけますか？

そのスクリプトは残念ながら私には機能しませんでした。昨日試してみました。 何か間違ったことをしたのかもしれませんが、yarn.lockファイル全体がスクリプトによって「空に」なりました。

これがどれほど適切な回避策であるかはわかりませんが、私が書いたこのスクリプトを実行しました。

const fs = require('fs')
const lockfile = require('@yarnpkg/lockfile')
const package = require('./package.json')

const lock = lockfile.parse(fs.readFileSync('yarn.lock', 'utf-8')).object

const allDeps = new Set()

const parseDep = ([name, version]) => {
  allDeps.add(`${name}@${version}`)
}

Object.entries(package.dependencies).forEach(parseDep)
Object.entries(package.devDependencies).forEach(parseDep)

const newLock = Object.fromEntries(Object.entries(lock).filter(([dep]) => allDeps.has(dep)))
const newLockString = lockfile.stringify(newLock)

fs.writeFileSync('yarn.lock', newLockString)

次にyarn installを実行すると、間接的な依存関係の最新バージョンがインストールされているようです。

深い/間接的な依存関係をうまく解決することができました。 いつ公式サポートを受けるのかしら。

https://medium.com/@ayushya/upgrading -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

私はyarn.lockを再生成するリスクを解決して説明し、何をすべきかを提案しました。

これが皆さんにも役立つかどうか教えてください。 または、アップグレードのプロセスを改善するための提案。

@ayushyaうーん、それはうまくいくようです、天才。

間接的な依存関係（または他のコマンド）へのyarn upgradeが含まれるパッチをyarnが受け入れるのだろうか？

@jrochkind直接の依存関係でなくても、 yarn upgradeの間接的な依存関係をアップグレードすると予想していました。 この機能がないと、間接的な依存関係の更新に何年も遅れることがあります。

私の場合、 fseventsをアップグレードしようとしていたので、 yarn install （https://github.com/fsevents/fsevents/issues/278）を実行したときにエラーが発生しませんでした。 ）。 fseventsは、私が直接使用するパッケージではありません。 webpack-dev-serverが使用するパッケージです。 しかし、驚いたことに、このアプリにwebpack-dev-serverが最初にインストールされたとき、私は存在するバージョンにロックされていました。

私はそれをアップグレードするためにこのトリックを使わなければなりませんでした、それは完全なハックのようでした。 https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

回避策は機能していません。残念ながら、古い深い依存関係は、それらを削除した後、yarn.lockファイルに再び追加されました。 ヤーンインストールを実行した後、node_modulesフォルダーとyarn.lockファイルに戻ってそれらを見ることができます。

おそらく回避策は糸のワークスペースと互換性がありませんか？

@FelipeLujan回避策が機能する場合、深い依存関係は引き続きyarn.lockファイルに追加されます（これは予想されます）が、新しいバージョンでは追加されます。 ただし、新しいバージョンがリリースされており、依存関係ツリーで許可されている場合にのみ、新しいバージョンを使用します。 一部の中間依存関係がアップグレードを許可しない制限を表している場合でも、それらをアップグレードすることはできません。 それらは、ツリーの制限によって許可されている最新のものにアップグレードされます。

私は糸のワークスペースを使用していませんので、それが適切かどうかはわかりません。

@FelipeLujanAFAIKヤーンワークスペースも同様に機能します。

パッケージセクションを削除する回避策は、パッケージを最新のMINOR/PATCHバージョンにのみアップグレードします。
パッケージを新しいメジャーバージョンにアップグレードする場合は、 yarn why package-name-hereを実行しているパッケージ依存関係チェーンを見つけて、そのチェーンの最上位にあるパッケージをアップグレードする必要があります。

注意：パッケージを新しいメジャーバージョンにアップグレードすると、重大な変更が生じる可能性があるため、コードをテストしてください。

https://github.com/djmitche/yarn-minifyがこれに役立つ可能性があります。

@ayushyaの回避策は私にとって非常にうまく機能しており、yarn.lockを手動で編集して間接的な依存関係を削除してから、yarninstallを実行して新しいバージョンで再度追加します。

私には、これは、yarn.lockを手動で編集する必要があるのではなく、yarnに組み込む必要がある機能のように見えます。 依存関係を削除してyarnインストールを実行するように手動で編集したかのように、機能を作成するのはかなり難しいようです。 この機能は本当に糸に組み込まれるべきだと思いますが、なぜそうでないのかについては少し混乱しています。

深い/間接的な依存関係をうまく解決することができました。 いつ公式サポートを受けるのかしら。

https://medium.com/@ayushya/upgrading -javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

私はyarn.lockを再生成するリスクを解決して説明し、何をすべきかを提案しました。

これが皆さんにも役立つかどうか教えてください。 または、アップグレードのプロセスを改善するための提案。

これは、@alex-thewsey-ibmによって提供されたのと同じ解像度だと思います。 その特定の依存関係をyarn.lockから削除することは私を助けました。
とにかく、このハックをありがとう☺️

$＃ package.json resolutionsを使用すると、うまくいきましたhttps://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

これにより、少なくともいくつかの警告が返されます。

yarn add [email protected]
yarn upgrade is-alphabetical

これは私が代わりに得るものです：

success Saved lockfile.
success Saved 0 new dependencies.

新しいis-alphabeticalパッケージバージョンが利用可能であっても、 package.jsonとyarn.lockの変更はありません。