これはバグではないと思います。 問題を再現できましたが、違いは

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

この変更はロックファイルの最適化であり、セマンティクスは変更されません。 yarn install実行時にロックファイルの更新が必要になったときに警告を追加する予定ですが、ロックファイルを同じままで正確に保つには、 --frozen-lockfileオプションを使用する必要があります。

これは少し直感的ではないことを認めなければなりません。私たちはこれに対する良い解決策を考え出そうとしています。 ＃4147のディスカッションをフォローするか、ディスカッションに参加できます。

これがバグではなく、＃4147が議論を続けるのに適した場所であることに同意する場合は、問題を閉じてください:)

@BYKあなたの思慮深い応答に感謝します。 ＃4147を読んだ後、私はこの問題を解決することについてフェンスにいます。 ここでもう少し議論が役立つことを願っています。

4147は、yarn.lockとpackage.jsonが同期していない場合にのみ関係しているようです。実際、最適化について言及されているのは、このコメントだけです： https ： yarn.lock変更がに行われていないファイルpackage.json 。

yarn.lockファイルは、依存関係が何らかの形で変更されている場合にのみ変更する必要があるように思われます。 実際には、この時点まで、私は彼らが変更見ればというのが私の開発者に言ってきたyarn.lock 、ファイルを実行するには、それの時間yarn install 。 最近のアップグレードで、いくつかの報告によると、私の変更を受け取り、 yarn install後、ロックファイルが変更されました（最適化）。 これは混乱を招く状況になります-彼らは変更をコミットする必要がありますか？ どういうわけか、ロックファイルを事前に最適化する必要がありますか（それも可能ですか）？

短期的には、すべてのリポジトリで--frozen-lockfile trueを.yarnrcに追加する必要があるようですが、このソリューションの大ファンではありません。 ＃4147ここで、 package.jsonを編集してから、 yarn installます。

ヤーンを呼び出すとyarn.lockが変更される可能性がありますか？

@BYKあなたがとても忙しいことを知っているので、これについてあなたに迷惑をかけて申し訳ありません-しかし、私はこれについて決定的な答えを得ることを望んでいます。 依存関係の変更をチームに配布するためのワークフローは、次のようになりました。

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

これにより、ロックファイルが適切に更新され（＃4476を参照）、チームメイトがロックファイルの変更をチェックインしないようにロックファイルを最適化するようです。

私のチームは糸を間違って使用していますか？ installコマンドごとにロックファイルが変更されることを期待する必要がありますか？

@artlogic IMHO 、チームメイトは、yarn installは直感に反しますが、それでもチームの各開発者が安全にコミットできるものであるという考えに同意します。 なぜそれを禁止したいのか分かりません。

そうは言っても、ロックインされたバージョンをほとんどあきらめているため、ワークフローによって予期しない副作用が発生する可能性があります。 ロックファイルを削除すると、yarnはすべての依存関係バージョンを再度解決する必要があり、 package.json指摘されている最新バージョンをフェッチしようとするため、破損する可能性があります。 将来のバージョンで複数の依存関係が同時に壊れた場合。

それでもインストールがロックファイルに触れないように強制したい場合は、 frozen-lockfileフラグを使用する必要があります。

 yarn add {blah}

ロックファイルをチェックインすると、別の開発者が使用します。

   yarn install --frozen-lockfile

追加しないでください--frozen-lockfileにtrueで.yarnrcそれは、これまでの更新からあなたを防ぐよう、以下を参照してください。＃4570

依存関係をアップグレードする場合は、次を実行します。

 yarn upgrade

1つの依存関係のみをアップグレードする場合：

  yarn upgrade {blah}

1つの依存関係の特定のバージョンをインストールすることもできます。

  yarn install {blah}@1.5

これにより、長期的にはより微調整が可能になり、頭痛の種が減ります。

@ k0pernikus-詳細な回答ありがとうyarn upgradeが多少壊れているように見えるという事実は、この問題とは何の関係もありません。

ワークフローに関しては、1人の開発者が新しい依存関係の維持/テストを担当し、他の開発者がコードベースで作業しているのは私のチームだけだとは想像できません。 何が起こったのかという大きな問題は、新しい依存関係をインストール/テストし、全員にyarn installを実行するように指示してから、変更されたyarn.lockをコミットする必要があるかどうかについて4〜5の質問をすることです。 。 「ロックファイルが変更された場合は、コミットしてください」と言った場合、その時点で次のようなコミットロックが発生する可能性があるため、状況が悪化するようです。

• 変更されたyarn.lock（dev4）
• 変更されたyarn.lock（dev3）
• 変更されたyarn.lock（dev2）
• 変更されたyarn.lock（dev1）
• 更新された依存関係（私）

ただし、これはyarnの意図したとおりの方法である可能性があるため、私のチームのプロジェクトでは、すべてのリポジトリを変更して、 addとupgrade原因となるように凍結ロックファイルを使用します。変更するロックファイル。

もう1つのシナリオ...クローンを作成してインストールするたびにロックファイルが変更される可能性があるため、多くの貢献者がいるプロジェクトにとって、これは潜在的な迷惑になる可能性があるようです。 私は確かにプルリクエストでこれらの最適化を望んでいません。 ヤーンを使用するほとんどのFOSSプロジェクトもフリーズロックファイルに移行する意図はありますか？

@artlogic私たちのチームは、まさにこの理由で、プロジェクトの.yarnrcに--install.pure-lockfile trueを持っています。

@ jboler-私はその設定を見たことがありませんでした。 確認する必要がありますが、すべてのリポジトリと、所有しているFOSSプロジェクトのすべてのリポジトリの.yarnrcにそれを追加することを提案しているようです。

ヤーンチームの誰かが、 yarn installが実行のたびにロックファイルを変更できる（依存関係に変更がないにもかかわらず）ことを意図していることを確認できたら、この問題を解決します。

@artlogic応答が遅れてすみません。

重要なのは、 yarn installがロックファイルを変更する可能性があるのは__expected__です。 これは理想的ではなく、より良いコミュニケーションが必要であることを私は知っています。 私は本当にもっと良いデフォルトを持ちたいのですが、それまでの間、 @ jbolerのようなものが提案されましたが、代わりに--frozen-lockfile使用するのが、次のようなさまざまなシナリオで糸がどのように動作するかを理解するまでは最善の解決策になると思いますyarn addなどを使用する代わりに、 package.jsonを編集して依存関係を更新することを好むワークフロー。

@ BYK @ artlogicに同意しました。 この動作は非常に紛らわしいです：

何が起こったのかという大きな問題は、新しい依存関係をインストール/テストし、yarn installを実行するように全員に指示してから、変更されたyarn.lockをコミットする必要があるかどうかについて4〜5の質問をすることです。

私たちのチームは、毎日yarn installを実行する

@vkrol Yarnが動作を変更するまで問題を回避するために、 --install.frozen-lockfile trueまたは--install.pure-lockfile trueを含む.yarnrcファイルをチェックインできるはずです。 それは役に立ちますか？

@BYK pure-lockfileは役に立ちますが、 frozen-lockfileは役に立ちません。 私が正しく理解していれば、frozen-lockfileが有効になっていると、 yarn installはエラーで失敗します。 私たちの場合、この動作は絶対に受け入れられません。

@vkrol私の好みはfrozen-lockfile 。これは、ロックファイルを変更する必要があり、一貫性がない場合にのみ失敗するためです。 pure-lockfileを使用すると、ロックファイルが役に立たなくなったり、非常に不正確になったりする可能性がありますが、それでも失敗することはありません。 ヤーンは、計算した内部解像度を使用するだけです。 チームメンバー全員がまったく同じバージョンのYarnを使用している場合、これは問題ありません。 そうでなければ、それは危険かもしれません。

@BYK多分私はfrozen-lockfileの振る舞いを正しく理解していません。 ロックファイルがpackage.jsonコンテンツと一致しているが、内部最適化が必要な場合は失敗しますか？

@vkrolファイルをさらに最適化できれば失敗することはありませんが、package.jsonと一貫性があり、それ自体も一貫性があります。 そうでない場合、これはバグです。 これに対するテストもあります： //github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK私はそれについて知りませんでした。 このオプションを試してみます、ありがとう！ この事実はどこかに文書化されるべきだと思います。

@BYK

ファイルをさらに最適化できれば失敗することはありませんが、package.jsonと一貫性があり、それ自体も一貫性があります。

このフラグを使用することのいくつかの欠点を見つけました。 このコマンドの繰り返しの呼び出しよりもyarn.lockを最適化できる場合、 yarn install --frozen-lockfileは、このフラグがない場合のように「整合性」チェックを介して最適化されません。 これはバグですか？ 別の問題を作成する必要がありますか？

@BYKご回答ありがとうございます。 私のチームのプロジェクトでは、現在frozen-lockfileおり、（比較的）正常に機能しています。 しかし、この問題は私にとってはかなり懸念されています。 具体的には、 yarn install実行しているときに、yarnがロックファイルに対して行っている不要な最適化です。

これは、この動作が問題を引き起こす場所について私が示すことができる最も明確な例です。

1. yarn add [blah]を使用して新しい依存関係を追加し、更新したpackage.jsonとyarn.lockをコミットします。
2. 私のパッケージの寄稿者は変更をプルダウンし、 yarn.lockが更新されたことに気づき、 yarn installます。
3. 場合によっては、これらの寄稿者は、インストール後に変更されたyarn.lock終わることがあります。 この場合、彼らは何をすべきですか？ 誰が最初にプルリクエストを送信できるかを確認するのは競争ですか？

明確にするために、 package.jsonが変更されている場合、 yarn install yarn.lock変更しても問題はありません。 私の問題は、 package.jsonが変更されていない場合の最適化です。 私は3つの可能な解決策を見ます：

1. 依存関係を一元的に管理するプロジェクトに、 --install.frozen-lockfile trueを.yarnrcファイルに追加するように指示します。 これはおそらくたくさんのプロジェクトになるでしょう-私が推測するほとんどのNPMパッケージ。
2. 追加フェーズ中にロックファイルを最適化するようにヤーンを強制するスイッチを提供します（例： yarn add --optimize [blah] 。 次に、パッケージメンテナに常にそのスイッチを使用するように指示します。
3. package.jsonが更新されたように見えない限り、インストールフェーズ中にyarnがyarn.lockを最適化することを禁止します。

私はオプション3を提唱していますが、オプション2も妥当な選択であることがわかりました。

御時間ありがとうございます！

yarn installがyarn.lockファイルを更新せず、代わりに「yarn.lockファイルが古くなっています。 yarn blahを実行して今すぐ更新 `。

@BYKなぜ、yarnはadd / upgradeが実行されているときではなく、 yarn install yarn.lockに最適化を適用しないのですか？

編集：タイプミスを修正

@ spencer-brown：私が見たものに基づいて、実際にはインストール時に最適化を適用します-それは私が問題だと思うものです

ヤーンアドでyarn.lockの最適化を実行するべきではありませんか？ とにかくyarn.lockは変更されます。 これは@artlogicの最近のコメントのオプション2ですよね？ なぜ最適化が行われないので、他の誰も別のyarn.lockの変更をコミットする必要はありませんか？

@artlogic oops、typo：）-私のコメントは「does」と言うべきです。 編集。

私たちはcomposerを頻繁に使用し、 composer installがロックファイルに触れることはありません。

ロックファイルに変更または最適化を行うには、 composer updateまたはcomposer require （ yarn add相当）を実行する必要があります。

長年、 composer installあいまいな動作について心配する必要はありません

ヤーンの役割は少し異なりますが、composerには、 composer.jsonが手動で更新され、ロックファイルと同期しなくなるという同等の問題があります。 現在、 composer installはcomposer.jsonファイルを完全に無視し、警告を発行します。

私たちはcomposerを頻繁に使用し、 composer installがロックファイルに触れることはありません。

ロックファイルに変更または最適化を行うには、 composer updateまたはcomposer require （ yarn add相当）を実行する必要があります。

長年、 composer installあいまいな動作について心配する必要はありません

ヤーンの役割は少し異なりますが、composerには、 composer.jsonが手動で更新され、ロックファイルと同期しなくなるという同等の問題があります。 現在、 composer installはcomposer.jsonファイルを完全に無視し、警告を発行します。

ねえ、子供たち、ロックファイルはその後のインストールで決して変更されるべきではありません。 それはばかげている。 最適化に触れる価値があると思われる場合は、バージョン管理に入らない別のファイルを作成してください。

BundlerのGemfile.lockと同様に、yarn.lockの要点は、yarnのインストールが実行されるたびに、すべての環境で確定的な結果を保証できることです。 ヤーンのインストールによってロックファイルが変更されると、その保証が失われます。 ヤーンの追加やヤーンの更新などの他のコマンドは、明らかにyarn.lockを変更する必要がありますが、ヤーンのインストールは変更しないでください。 私たちのチームは、異なる環境にわずかに異なるパッケージバージョンがインストールされているという問題に遭遇しました。これは、まさに私たちが望んでいないことです。

yarn install --pure-lockfileをデフォルトにする必要があり、現在の動作を取得するための--fix-my-dev-process-inconsistencies-for-me-magicallyオプションがある可能性があると思う傾向があります。

@ryancastle --pure-lockfileは、更新がロックファイル用であることを通知しません。 生成されないだけです。 これでも予期しない動作が発生する可能性があります。 更新が必要な場合、 --frozen-lockfileは失敗します。

私はしばらくの間.yarnrcで--install.frozen-lockfile trueを操作してきましたが、それは正常に機能しているようです。 秘訣は、そのフラグを有効にせずに、リポジトリの最初のyarn.lockを作成することです。 一度作成されると、インストールではyarn.lock変更できませんが、更新では変更できます。 このワークフローを使い始めると、 yarn.lockへの偶発的な変更の数はゼロになりました。

@artlogic追記：私が持っていたfrozen-lockfile true私に.yarnrcへの意図的な変更をしただけでなく、私たちが問題に走ったとして、今私は、ビルドサーバー上で、それを強制yarn.lock開発者が手動でpackage.json編集したか、npmを使用して依存関係を追加したため、たとえば、変更されたpackage.jsonをyarn.lockに同期しようとしたときにyarn.lockが作成されませんでした。

参照： https ：

@ k0pernikusのユースケースは、 --frozen-lockfileをyarn installデフォルトにしない理由です。 私は正直良いの妥協が編集人々妨げることなく、どうなるか分からないpackage.json当時とは、実行yarn installロックファイルを更新することを。 フラグまたはyarn syncような新しいコマンドを提案しましたが、実装する前に、アイデアを具体化してコミュニティが判断する必要があります。

さらに、これは重大な変更になるため、Yarn 2.xが必要になります:)

フラグまたはyarnsyncのような新しいコマンド

私にはいいですね👍。 yarn installは、「package.jsonとyarn.lockが同期していません。「yarnsync」を実行してロックファイルを更新してください」という通知を表示する可能性があります。

package.jsonを編集してから、yarninstallを実行してロックファイルを更新する人々を妨げることなく適切な妥協点が何であるかを正直に知りません。

ある時点で、適切なワークフローを決定する必要があると思います。 私には、これを有効にすることは、アンチパターンを奨励するように思えます。

フラグまたはyarnsyncのような新しいコマンドを提案しましたが、実装する前に、アイデアを具体化してコミュニティが判断する必要があります。

私には、これは合理的な妥協のように思えます。 package.jsonを手動で編集する必要がある場合は、コマンドを実行して同期を取り戻すのが理にかなっています。

これが私が見たいものです：

• yarn installなしのyarn.lockは、 yarn.lockます。
• yarn installを含むyarn.lockは、それを変更しません。 yarn.lockとpackage.json間に不一致があることがわかった場合、エラーが返されます（ @indeyetsが示されているように）。
• yarn sync （またはyarn install -s ）は、 yarn.lockをpackage.jsonと同期します。

package.jsonがロックファイルと同期していない場合でも、 yarn installがyarn.lock変更するという根本的な懸念があります。 上記で、いくつかの「最適化」が実行されていることがわかります。 重大な変更を加えることなく、少なくともこの動作を無効にすることは可能でしょうか？

package.jsonがロックファイルと同期していない場合でも、yarnのインストールによってyarn.lockが変更されるという根本的な懸念があります。 上記で、いくつかの「最適化」が実行されていることがわかります。 重大な変更を加えることなく、少なくともこの動作を無効にすることは可能でしょうか？

ここで同じ感情。 これが、この問題が未解決のままである特定の理由だと思いました。 「同期」は＃4147で議論されているので

そもそもこの問題を検索したのはそのためです。

これと＃4147をマージしませんか？

@BYKここで説明したことのほとんどすべてを＃4147とマージできると思います。 前にも言ったように、私がまだ気になっているのは、 package.json変更が加えられていない場合でも、 yarn installがyarn.lockに対して実行する「最適化」だけだと思います。 。

私の考えでは、yarn 2.0への途中の一時的なギャップとして、これらの最適化を無効にする必要があります。 これが重大な変化になるとは思いません。

@artlogicに100％同意し

CircleCIをセットアップしていましたが、ビルドが失敗し続け、 yarn.lockキャッシュの問題まで追跡しました。 Railsから来ているので、installコマンドでロックファイルがロックされると思います。

これは、CircleCIでのキャッシュチェックのために提案されているものです： https ：//circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

これは、yarn.lockが変更されるべきではないのに変更される可能性があるため、機能しません。

参考までに、macOS 10.13.6のyarn1.10.1で、OPのバグ刺激を試したところ、yarn.lockが変更されていないことがわかりました。 言い換えれば、私が試したとき：

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

したがって、yarn 1.10.1を使用した場合、 yarn installは、yarn 1.0.1を使用した場合のOPの場合のように、 yarn.lock変更しませんyarn installた。 （OPと同じように、これは良いことだと思います。）

@dtgriscomコルドバで問題が発生しなくなったことは素晴らしいことです！ それが完全に修正されたのか、それともyarnがインストール時にロックファイルを最適化しようとするのか疑問に思っていますか？

知っておくといいですね。 問題はパッケージ固有であるとおっしゃいました。 バージョン固有の場合もあります。 （「変更してはならないものを変更したい」という理由を聞いたことがありません。「最適化しています」以外は...）

install操作はデフォルトで決定論的である必要があることに心から同意します。 .lockファイルを更新するには、開発者がファイルに変更を加えることがわかっているアクションを実行する必要があります。 たとえば、 yarn install --optimizeようなものを実行して、パッケージの現在の状態を壊さない小さな最適化を可能にすることができます。

許可なしにロックファイルが変更されていないことを確認するために、ドキュメントを調べなければならない個別のオプションを追加することは、特に失敗を引き起こす可能性がある場合、かなり混乱します。 開発者として、私は自分が使用するツールを制御できることを期待しており、この振る舞いは私からそれを奪うように感じます。

依存関係をインストールするときに、ロックファイルを変更せず、ロックファイルのみを操作するように、デフォルトの動作を反転することを再検討してください。 package.jsonがロックファイルと同期していないという警告を伴う整合性チェックは、本当にすべての人が必要とします。

ロックファイルは新しい依存関係を追加したり更新したりするときにのみ変更されるため、ロックファイルの変更を含むPRはマージされないことを人々に伝えてきました。 これは、インストールドキュメントに記載されている内容です。

yarn install

package.json内にリストされているすべての依存関係をローカルのnode_modulesフォルダーにインストールします。

yarn.lockファイルは次のように使用されます。

• yarn.lockが存在し、 package.jsonにリストされているすべての依存関係を満たすのに十分な場合、 yarn.lock記録されている正確なバージョンがインストールされ、 yarn.lockは変更されません。 。 Yarnは新しいバージョンをチェックしません。
• yarn.lockが存在しない場合、またはpackage.jsonリストされているすべての依存関係を満たすのに十分でない場合（たとえば、 package.json依存関係を手動で追加した場合）、Yarnはpackage.jsonの制約を満たす利用可能な最新バージョン。 結果はyarn.lock書き込まれます。

yarn.lockが更新されないようにする場合は、 --frozen-lockfileます。

上記で発生する可能性のあるこれらの最適化があるため、ドキュメントは間違っていますか、それとも当面は考慮すべきバグですか？

ps。 それはまだ起こります、そして、それが起こったとき、 yarn --frozen-lockfileは失敗しません。

現在、 .yarnrcファイルで--frozen-lockfileしています。これにより、異なるマシンでyarn installを実行しているときに、yarnがyarn.lockファイルを変更するのを効果的に防ぐことができます。 しかし、これはyarn add blahblahが私のyarn.lockを変更することも防ぎます。 それは正しい動作ですか、それとも何かが足りませんか？ スレッド全体を読んだのですが、今のところ--frozen-lockfileが推奨されるアプローチのようです。

@konekoyaはい、あなたはあなたが現在使用しなければならないということは正しいです

yarn install --frozen-lockfile

yarn.lockが更新されなくなるため、 .yarnrcの設定に依存することはできません。

.npmrcと.yarnrcコンテンツによっては、使用できる場合があります

yarn install --no-default-rc {dependency}

しかし、私はそれに依存しません（rcファイルに他の設定があるとすぐに壊れてしまうためです）。

私のコメントと関連する問題を参照してください：＃4570、特に。 私の結論。

@ k0pernikusをクリアしてくれてありがとう。 あなたはちょうど私の日を作りました:)

@BYKなぜyarnはadd / upgradeが実行されているときではなく、 yarn install yarn.lockに最適化を適用するのですか？

ここでの@ spencer-brownのコメントは、この問題を「修正」するための鍵だと思います。 自分でテストしてyarn upgradeから、 yarnを実行すると、「すでに最新です」と言われました。 私の削除された私はnode_modulesと走っyarnその後、私はから得た1プッシュしていた場合、私のプロジェクトでは、他の開発者が終わっているだろう「最適化」ロックファイルをもたらしたyarn upgrade 。

ここで、 yarn upgrade （およびyarn add ）がyarn installと同じ最適化を実行する場合、そもそもこの問題は発生しません。 既存の機能を壊したくないという話がたくさんあり、 yarn upgradeとyarn add後に最適化を実行すると、何かが壊れるとは思われません。少し遅くなります。

回避策として、ロックファイルを他のユーザーにプッシュする前に、ロックファイルを更新して「最適化」を強制する必要がある場合は常に、すべての開発者にnode_modulesを削除するように指示することを考えています。 または多分彼らはyarn upgrade && yarn prune実行することができます-多分それはトリックをするでしょうか？

回避策として、ロックファイルを他のユーザーにプッシュする前に、ロックファイルを更新して「最適化」を強制する必要がある場合は常に、すべての開発者にnode_modulesを削除するように指示することを考えています。 または多分彼らはyarn upgrade && yarn prune実行することができます-多分それはトリックをするでしょう

更新：手動でプルーニングを実行することはできません。次のメッセージが表示されます：_「プルーニングコマンドは必要ありません。 yarn installは無関係なパッケージをプルーニングします」。 are _ "Already up-date" _ node_modulesを削除してから、 yarnを実行してプルーニングを実行すると思います。

私にとって、 yarn最大のセールスポイントは、予測可能で信頼性の高いロックファイルの動作です。 yarn installのロックファイルを変更すると、本当に不安になります。

私にとって、 yarn最大のセールスポイントは、予測可能で信頼性の高いロックファイルの動作です。 yarn installのロックファイルを変更すると、本当に不安になります。

ロックファイルは、何がインストールされるかを正確に指定したものとして提示されるため、何がインストールされるかを心配する必要はありません。 同じロックファイルを使用すると、毎回同じインストールが行われます。 ただし、 yarnは、独自の理由で、警告なしに、独自のイニシアチブでロックファイルの内容を変更する場合があります。 はい、「ファイルの変更はインストールされるものを変更しない」と主張することはできますが、なぜそのような明確な保証を取り、それを混乱させるのですか？ 変更されたロックファイルを再コミットする必要があるのか​​どうか疑問に思うのはなぜですか？ なぜあなたの主な名声を汚すのですか？

これは本当に信じられないほどです。 他の人はすでにそれをよく述べています。 ロックファイルはインストール時に変更しないでください。 これは、コミットワークフローに悪影響を及ぼします。 私たちのチームのすべての開発者は、どのような状況でロックファイルを変更できるかを知っています。 依存関係を更新せずにロックファイルを変更すると、不必要な混乱と余分なチェックが発生します。 これは壊れたばかりの基本的なパッケージマネージャーUXです。 修正してください。

Node.js 13から14に移動すると、 yarn installとすべてのyarn.lockファイルが変更され、なぜだろうと思っていたので、この動作に驚いたばかりです...

yarn.lockファイルを何らかの方法で_最適化_した場合、適切な動作は警告を発することだと思います。