Yarn: `--pure-lockfile`を` install`のデフォルトにします

同意します。 yarn installが最初にデフォルトでロックファイルを書き込む理由については、ロックファイルの概念全体と矛盾しているように思われるため、議論する必要があります。 デフォルトでバージョンをロックしていないのに、なぜロックファイルがあるのですか？

yarn installが存在しない場合、つまり誰かがプロジェクトをyarnを使用するように変換している場合、ロックファイルを作成する場合がありますが、常にそれを書き込む理由は明確ではありません。 デフォルトでは、変更アクションのみがロックファイルを更新する必要があるというadd/upgrade/removeに同意します。

add/remove/upgradeなしでロックファイルを変更する方法があるはずです。例：Yarnをアップグレードし、新しいロックファイルバージョンを使用するシナリオでは？

私はオプションが逆にされる可能性があると思います

yarn install --save-lockfile

18：53で2016年10月17日、ジェームズ・井手[email protected]は書きました：

追加/削除/アップグレードせずにロックファイルを変更する方法があるはずです
例：Yarnをアップグレードし、新しいロックファイルを使用するシナリオ
バージョン？

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

私もこれに混乱しています。 現在のデフォルトの動作の理由は何ですか？

Afaik、デフォルトの動作には強い理由はありませんでした。
アイデアは、人々のロックファイルを「常緑」に保つことだと思います。

ところでPRは大歓迎です

その理由は、元々、糸がinstall/add/upgradeに分割された単一のinstallコマンドで設計されていたためだと思います。

だから、私がこれを正しく理解しているかどうかを確認するために：

yarnはすべての依存関係をインストールし、ロックファイルも変更します。 CIサーバーでは、 yarn install --pure-lockfileを使用する必要がありますか？
インストール中にロックファイルが変更されるのはなぜですか？ 何もアップグレードしていないので... Yarnは、ロックファイルに記述されているようにパッケージをインストールする必要がありますよね？

説明してくれてありがとう！

問題は、ロックファイルがデフォルトで純粋である場合、それは別のコマンドになるため、人々はそれを更新するのを忘れてしまうということです。

@kittensロックファイルは、パッケージの追加/削除/アップグレード時にのみ更新されるべきではありませんか？ それらは、初期インストールだけでなく、常にロックファイルをアップグレードする必要があります。

問題は、ロックファイルがデフォルトで純粋である場合、それは別のコマンドになるため、人々はそれを更新するのを忘れてしまうということです。

それが問題になるかどうかは、パッケージマネージャーの主な目的が何であるかによって異なります。

私の意見では、パッケージマネージャーが果たす役割の1つは、プロジェクトの開発をできるだけ簡単に開始できるようにすることです。 単純なyarn install 、混乱を招くことなく、開発を開始するために必要なすべてのパッケージを取得できます。

npmを使用すると、開発者の多くのインスタンスがプロジェクトに参加しましたが、プロジェクトが自分のマシンで機能しないことがわかりました。 これらのインスタンスは、一時的な依存関係がバージョンを重大な変更のあるバージョンにぶつけたり、単にsemverに従わなかったりしたために発生しました。 yarnこれらの問題が解決することを期待していましたが、プロジェクトのすべての開発者がyarn install --pure-lockfileを実行して、プロジェクトが確実にビルドされるようにする必要がある場合は、そうではありません。ケース。

パッケージマネージャーのもう1つの役割は、プロジェクトに依存関係の制御を与えることです。 デフォルトで純粋になっている場合、開発者はyarn outdatedを見て古いバージョンを確認し、変更メモを確認して、重大な変更を回避できます。 これにより、開発者は、偶発的なロックファイルのコミットを回避するために、開発者がgit commit -aを実行することを禁止するのではなく、特定のリリース期間内のバージョンのみをバンプするように完全に制御できます。

@esphenの言うことすべてに同意します。 純粋な動作がYarnのデフォルトではないことに驚いています。この種の一貫性が、YarnがNPMよりも優れている主な利点だと思いました。 これが、私が見ているようにNPMから切り替える最も説得力のある理由であるはずです。

yarnを数日間使い始めた後、ビルドを壊して完全に驚いた。 ドキュメントの多くを読んだ後、 --pure-lockfileがデフォルトの動作であり、shrinkwrapを使用したnpmよりも優れていると正直に思いました。 デフォルトにしてください:)

誰かがちょうどNPMを使用して更新されるシナリオを想像@ide package.jsonどのように、 yarn.lock更新されることになるだろうか？

誰かがロックファイルが予期せず変更される原因となるシナリオを書いてくれませんか？ この変更は、重大な一つであり、操作はそれがなどが更新される結果何を思い出すにはオーバーヘッドの多くを意味し、明示的であることを、それへの更新を要求することにより、ロックファイル二級市民を作るん

上記の詳細：私たちのビルドには、サブ依存関係としてGithubからのコーヒースクリプトが含まれています。 coffeescriptがいくつかのコミットをプッシュし、ビルドプロセスでyarn install実行するだけで変更されたyarn.lockを取得しました：

diff --git a/foo/yarn.lock b/foo/yarn.lock
index ec667fa..bb1f6ae 100644
--- a/foo/yarn.lock
+++ b/foo/yarn.lock
@@ -930,9 +930,9 @@ code-point-at@^1.0.0:
   version "1.6.3"
   resolved "https://registry.yarnpkg.com/coffee-script/-/coffee-script-1.6.3.tgz#6355d32cf1b04cdff6b484e5e711782b2f0c39be"

-"coffee-script<strong i="8">@github</strong>:jashkenas/coffeescript":
+coffee-script@jashkenas/coffeescript:
   version "1.11.1"
-  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/887052de079b2f0af9f080031a00bb7544eaca08"
+  resolved "https://codeload.github.com/jashkenas/coffeescript/tar.gz/0d132318ce8f7116a436d97db1f2a5c8b1dedf28"

 [email protected]:
   version "0.3.0"

誰かがロックファイルが予期せず変更される原因となるシナリオを書いてくれませんか？ この変更は深刻なものであり、ロックファイルの更新を明示的に要求することにより、ロックファイルを2番目のクラスの市民にします。これは、どの操作によって更新されるかなどを記憶する上で多くのオーバーヘッドが発生することを意味します。

yarn installは、node_modulesをビルドするコマンドとして認識しています。
package.json、yarn.lock、cleanup node_modulesを変更するyarn addとyarn remove反対です。
addとremoveとは対照的に、私はinstall 100倍頻繁に実行します。特に、副作用が予想されないCIではそうです。

物事が変わるとは思わない場合の例：

1. 私はYarn0.15.0を使用しており、チームメイトはYarn0.16.0を使用しています。
   チームメイトによって生成されたyarn.lockに対してyarn installを実行するたびに、0.16.0によってyarn.lockのエントリ間にスペースが追加されたため、コミットしないように覚えておく必要のある変更されたyarn.lockファイルを取得します。
   およびその逆。
2. 私の他のビルドツールは、node_modules状態の「信頼できる情報源」としてyarn.lockに依存しています。 予期せず変更された場合、ビルドで非決定論が発生します

@kittens

問題は、ロックファイルがデフォルトで純粋である場合、それは別のコマンドになるため、人々はそれを更新するのを忘れてしまうということです。

誰かがnpmを使用してpackage.jsonを更新するシナリオを想像してみてください。yarn.lockはどのように更新されますか？

yarn installがyarn.lock更新しないと仮定した場合、 yarn.lockがpackage.jsonと同期していない場合も失敗し、 yarn install --save-lockfileすべてを同期に戻すには、

+1ヤーンインストールはyarn.lockを変更しないでください

1. デバッガーはossアプリです。 コントリビューターが_good_バージョンをyarnインストールして取得できるようにする必要があります。 npmをインストールしてもらい、推移的なプロパティのために壊れていると言っています。 ヤーンインストールでは、寄稿者はヤーンインストールを行い、ヤーンロックの変更をどうするかわかりません。

ロックファイルの更新については心配していません。 理想的には、depsが変更されたときにグリーンキーパーがこれを行い、ロックファイルの変更をマージできます。

私はそれについての現在の考えでこの問題を更新したいと思います。 @kittensと私は両方とも、いくつかの理由から--pure-lockfileをデフォルトにするべきではないと考えています。

それは、人々が依存関係を追加/削除/更新する方法から始まります。 そのためのコマンドはありますが、手動またはLernaなどの別のツールを使用してpackage.jsonを手動で更新するのが一般的な方法です。

package.jsonを手動で変更すると、Yarnとnpmの両方で、別のインストールを実行すると、 package.jsonと_syncs_されることが期待されます。 その意味で、 yarn installはほとんどyarn sync名前を変更できます。

同期のトピックでは、新しい依存関係を使用してインストールを実行すると、 node_modulesディレクトリにそれらの変更が反映されることが期待されます。 yarn.lockはnode_modulesアシスタントとして機能するため、同じように同期が保たれることを期待する必要があります。

あなたのpackage.jsonは究極の真実の源であり、それは糸へのインターフェースであり、それはあなたの構成であり、あなたがこれまでに気にかけるべき唯一のことです。 理想的な世界では、 yarn.lockをコミットするだけで、二度と考える必要はありません。

ちなみに、この問題への支持を表明している多くの人々は、ここで実際に議論されていることについて混乱していると思います。

デフォルトで--pure-lockfileを使用しても、Yarnが一貫性のある信頼できる結果を生成しないことを意味するわけではありません。 同じpackage.jsonは同じyarn.lockになり、100％のnode_modules同じ

package.jsonを更新すると、 yarn.lockファイルが更新され、次にnode_modules更新されます。 それは物事にとって非常に自然な秩序であり、私たちはそれをそのように保つべきです

package.jsonを更新したが、誰かが起動すると確信しているすべてを同期するためにyarn installを実行していない場合に、CIがさまざまな依存関係を取得できることに関して（問題）-私や他の人は、Yarnの統合についてさまざまなCIツールについて話してきました。人々がそれを大きな問題と見なす場合、デフォルトで--pure-lockfileを使用するように簡単にプッシュできます。

この変更を行うと、依存関係を変更するときに、はるかに頻繁に悪影響があります。 私がリストした理由のために、私はこの問題を閉じるべきだと言います。

@thejameskyle何かを明確にしていただければ幸いです：

1. 開発者は、依存関係"foo": "^1.0.0"を含むpackage.jsonを持っています
2. 開発者はyarn installます。 fooパッケージは現在バージョン1.0.0であるため、 [email protected]をロックするyarn.lockファイルを作成します。
3. 開発者はGitにyarn.lockを追加します。
4. 開発者はリポジトリのローカルコピーで単体テストを実行し、すべてが正常に機能します。
5. 開発者はリポジトリをCI（Travisなど）にプッシュします。
6. CIはyarn installを実行しますが、 fooがバージョン1.1.0に更新されたため、Yarnは[email protected]をインストールし、 yarn.lockを新しいバージョンのfoo
7. fooバージョン1.1.0重大な変更があったため、CIが破損しました

同様の状況は次のとおりです。

1. 開発者は、依存関係"foo": "^1.0.0" package.jsonを含む[email protected]としてロックインされ、 yarn.lockはGitに保存されます。
2. 単体テストは、開発者のリポジトリのローカルコピーで正常に機能します。
3. 寄稿者は、変更+プルリクエストを行う目的でリポジトリのクローンを作成します。
4. コントリビューターがyarn installを実行すると、バージョン[email protected]が取得され、 yarn.lockが更新されます。
5. fooバージョン1.1.0重大な変更があったため、寄稿者のビルドが壊れています。

そういう状況がほとんどの人が心配していると思います。

したがって、 yarn installの現在の動作に上記の問題がないことを明確にできれば、私たちの恐れのほとんどが取り除かれると思います。 ：+1：

これらの状況はどちらも当てはまりません。 依存関係が更新されたからといって、それを取得できるとは限りません。 package.json変更を加えた場合に限ります。

私が言ったように、これは実際のシナリオではない、これが人々が持っている唯一の懸念であるように思われるので、私はこの問題を閉じるつもりです。 この問題は、より多くの混乱を引き起こしている可能性があります。

しかし、私が上で報告したように、依存関係がgithubからインストールされている場合、それは悪い振る舞いをします

@adamchainz個別に修正する必要があり、コミットに簡単にロックできます

これらの状況はどちらも当てはまりません。 依存関係が更新されたからといって、それを取得できるとは限りません。 package.json変更を加えた場合に限ります。

@thejameskyle ：これが実際のシナリオではない理由がわかりません。 詳しく教えていただけますか？

入力がpackage.jsonで、出力がyarn.lockあるメモ化関数を想像してみてください。

1. 初めてあなたが合格package.jsonそれが作成されますyarn.lockと結果をキャッシュします。
2. 次回_thatsame_ package.jsonを実行すると、キャッシュされるため、結果はまったく同じになります。
3. package.jsonを変更すると、キャッシュが無効になり、 yarn.lockが再計算されます。

今話しているのは、＃3を取り除き、代わりにyarn.lockを、変更されたpackage.jsonによって無効化されていないかのように扱うことです。 これは、メモ化関数が持つのは本当に奇妙であり、Yarnが持つのは本当に奇妙な動作です。

コミットと新しいバージョンに関してパッケージに何が起こるかは関係ありません（git commitにバグがある場合は、個別に修正する必要がありますが、この問題とは関係ありません）。

私が思っていたよりも複雑です（各パッケージバージョンは個別に効果的に「メモ化」され、1つのパッケージのバージョンを変更しても、残りは無効になりません）が、今では誰もがポイントを獲得できることを願っています。

@thejameskyle ：わかりやすくするために（そして好奇心のために）、 yarn.lockファイルを含むプロジェクトがあり、誰かがリポジトリをプルダウンしたとします。 実行せずにyarn installやnpm install 、この人は新しい依存関係を追加しますpackage.jsonファイル、次に実行しますyarn install 。 この場合、既存のyarn.lockファイルは完全に無視されますか？

ここでは、解き明かそうとしたさまざまなことが起こっています（しゃれは意図されていません）。

まず、人々は私が議論の余地がないと思う多くの異なる要件を提起しました（そしてそれは私がすぐに得るであろう既存の振る舞いのバグのいくつかを作ります）。

元のバグレポートから。

環境（現在インストールされているヤーンのバージョン）に応じてロックファイルを変更すると、整合性が失われます。
期待される動作は何ですか？
ヤーンのインストールを行うときは、yarn.lockまたはpackage.jsonを記述しないでください。
ヤーンロックを更新するには、ヤーンアップグレードを使用します

より正確に言うと、私の意見では、期待されるセマンティクスは次のとおりです。

• package.jsonが最後にyarn.lock変更されてから変更されていない場合、 yarn.lockが真実のソースであり、更新しないでください。
• 場合package.json 、最後の時間以降に変更されたyarn.lock変更、更新yarn.lock満足そうpackage.jsonおよび更新node_modules 。
• yarn updateが実行されている場合は、すべての依存関係を再解決し、 package.jsonを満たすすべての最新バージョンを取得します。

つまり、リポジトリが最初にマシンにyarn.lockがチェックインされた場合、yarnは常にそれを信頼できる情報源として扱い、 yarn.lock更新を生成せず、ジャンプする必要があります。フェッチステップに直接。

これが現在の糸の振る舞いではない限り、それはバグだと思います。

@esphenは書いた：

同意します。 そもそも、yarn installがデフォルトでロックファイルを書き込む理由については、ロックファイルの概念全体と矛盾しているように思われるため、議論する必要があります。 デフォルトでバージョンをロックしていないのに、なぜロックファイルがあるのですか？

これが言おうとしているのは、既存のロックファイルがまだ最新の場合、yarnは新しいロックファイルを書き出すべきではないということだと思います。 私はそれに同意します。

デフォルトでは、変更アクションのみがロックファイルを更新する必要があるという

ここでの主な問題は、 package.jsonを変更すると、 yarn.lockが更新されるかどうかです。 私の意見では、 package.jsonへの変更がyarn.lockによって満たされない場合、 yarn.lock更新する必要があります。

ヤーンのようなロックファイルシステムの重要な不変条件は、通常のワークフローを使用して、開発者がアプリの実行時に実際に使用されるパッケージがpackage.json指定されたバージョンと一致することです。 package.jsonがyarn.lockと同期しなくなることが許可されている場合、これは真実ではなく、それを知る唯一の方法は、人間の読者がyarn.lockを注意深く読むことです。

ほとんどのユーザーがロックファイルについて考える最良の方法は、現在のpackage.json使用されたすべてのパッケージの正確なバージョンを表す実行中のヤーンのアーティファクトであるということです。 チェックインすることで、他の共同編集者、CI、および本番コードが同じバージョンを使用することが保証されます。

@Guuzは言った：

だから、私がこれを正しく理解しているかどうかを確認するために：
ヤーンはすべての依存関係をインストールし、ロックファイルも変更します。 CIサーバーでは、yarn install --pure-lockfile？を使用する必要があります。

この質問は、このスレッドで数人の人が作った感情を反映しています。

貨物には--lockedフラグがあり、「 package.jsonがyarn.lockによって満たされない場合、それはハードエラーです」と表示されます。 Bundlerにも同様のフラグ（ --frozen ）があり、HerokuがBundlerを採用したときに追加されました。これは、 Gemfileローカルな変更を加え、 Gemfile.lockチェックインを忘れた場合に、ハードエラーを発生させるためです。

アイデアは、通常の開発中に、 package.json変更を加えて、 yarn.lockが同期していることを確認できるようにすることです（ここでも、指定されたバージョンを確認するため） package.jsonは、実際に使用されるものと常に一致します）。

ただし、デプロイするときは、 package.jsonに変更を加え、ローカルのyarnコマンドを実行し、 yarn.lockチェックインを忘れたことを意味するため、分岐したことは事実上常にエラーです。 。 これは、 package.jsonのバージョンが、アプリケーションの実行時に使用される実際のバージョンと一致しないことを意味します。これは、yarnの基本的な不変条件に違反していると述べました。

@esphenは言った：

私の意見では、パッケージマネージャーが果たす役割の1つは、プロジェクトの開発をできるだけ簡単に開始できるようにすることです。 単純なyarnのインストールで、混乱を招くことなく、開発を開始するために必要なすべてのパッケージを取得できます。

これは議論の余地がないと思います。

npmを使用すると、開発者の多くのインスタンスがプロジェクトに参加しましたが、プロジェクトが自分のマシンで機能しないことがわかりました。 これらのインスタンスは、一時的な依存関係がバージョンを重大な変更のあるバージョンにぶつけたり、単にsemverに従わなかったりしたために発生しました。 私はyarnがこれらの問題を解決することを望んでいましたが、プロジェクトのすべての開発者がyarn install --pure-lockfileを実行して、プロジェクトがビルドされることを100％確実にする必要がある場合は、そうではありません。

yarn install --pure-lockfileを実行すると、ロックファイル内のバージョンがpackage.json指定されたバージョンと競合する場合でも、ロックファイルが尊重されることを意味します。 これは、開発者がpackage.json変更を加えた後、 yarn.lockをチェックインするのを忘れた場合にのみ、最初に発生するはずです。

パッケージマネージャーのもう1つの役割は、プロジェクトに依存関係の制御を与えることです。 デフォルトで純粋になっている場合、開発者は古いヤーンを見て古いバージョンを確認し、変更ノートを確認して、重大な変更を回避できます。 これにより、開発者は、偶発的なロックファイルのコミットを回避するためにgit commit -aの実行を禁止するのではなく、特定のリリース期間内のバージョンのみをバンプするように完全に制御できます。

package.jsonが変更されていない場合、私の意見では、 yarn.lockが更新されている場合はバグです。 バグの少なくとも1つのケースは、元のレポートにあるようです。

ロックファイルは、環境（現在インストールされているヤーンのバージョン）に応じて変更されます。

これは間違いであり、修正する必要があると思います。

スレッドの後半で、 @ thejameskyleは次の

入力がpackage.jsonで、出力がyarn.lockであるメモ化関数を想像してみてください。

私の見解では、これはまさに正しいメンタルモデルであり（「 yarn.lockは、 package.json変更された場合にのみ変更できます」）、抽象化がリークした場合は修正する必要があります。

@adamchainzは言った：

上記の詳細：私たちのビルドには、サブ依存関係としてGithubからのコーヒースクリプトが含まれています。 coffeescriptがいくつかのコミットをプッシュし、yarninstallだけを実行してビルドプロセスでyarn.lockを変更しました

以降：

しかし、私が上で報告したように、依存関係がgithubからインストールされている場合、それは悪い振る舞いをします

ここでの問題は、yarnがgitshaをロックされたバージョンのgit依存関係の一部として扱わないことです。 CargoとBundlerはどちらも、ロックファイルにシリアル化される「正確な」バージョンの概念を持っています。 gitソースの場合、「正確な」バージョンはSHAです。 あなただけで新鮮なクローンを作るときに、 package.jsonとyarn.lockと実行yarn 、正確にあなたが必要なコードを取得するために必要なすべての情報があります。

元のgitコードを確認するときに、このやり取りを見逃したことを告白する必要があります。 コードにはいくつかのSHA追跡がありますが、 yarn installは、ハイドレイテッド依存関係グラフがそれを尊重することを保証しません。

TL; DR

@thejameskyleと@kittensは、 yarn.lockをpackage.json自動的に同期させる必要があることに同意します。これは、ユーザーがpackage.json指定されたバージョンを想定できるはずだからです。アプリの実行時に使用されるものと一致します。

ただし、 package.jsonが変更されていない場合でも、 yarn.lockで不適切なチャーンを引き起こしているバグがいくつかあるようです。

• マシン間でヤーンバージョンを変更すると、ロックファイルが更新されます
• package.jsonが更新されていなくても、gitの依存関係が更新され、ロックファイルが更新されます。

また、Cargoの--lockedフラグのようなものも検討する必要があります。これは、開発者がpackage.jsonを更新し、更新されたyarn.lockチェックインを忘れた場合に、CIでビルドを高速で失敗させるために使用できます。

@thejameskyleありがとう！ ：心：私はあなたといること@kittensに同意yarn.lock変更した後に更新する必要がありますpackage.json

@wycatsいつものように非常に徹底的で洞察に満ちた投稿。 ：+1：私はあなたに同意します、そして私は--lockedフラグ（または同様のもの）のアイデアも好きです。 それについて新しい問題を作成する必要があります。

git SHAの問題を追跡するために＃1568を作成しました

@wycats 、解明された、非常に洞察に満ちた概要に感謝します！

つまり、リポジトリが最初にマシンに複製されたときに、yarn.lockがチェックインされた場合、yarnは常にそれを信頼できる情報源として扱い、yarn.lockの更新を生成せず、フェッチステップに直接ジャンプする必要があります。
これが現在の糸の振る舞いではない限り、それはバグだと思います。

それがまさにこの問題が開かれたシナリオです。
社内にはアクティブなバージョンのYarnがいくつかありますが、私たちの規模では、どこでもアトミックな更新を行うことはできないと思います。
ヤーン0.13、0.14、および0.15でのビルドでは、package.jsonが同期されていても、yarn.lockファイルにわずかなバリエーションが導入されました。
これにより、いくつかの問題が発生しました。たとえば、ソースツリーの変更によりキャッシュが無効になるため、バックビルドの速度が低下しました。
これにより、私といくつかのチームは数時間の作業を行いました。

@thejameskyle 、あなたの意見を共有してくれてありがとう。
package.jsonがyarn.lockと同期していないというシナリオは、公平であるとは考えていませんでした。 そして、あなたは有効なポイントを持っています。

ただし、 @ wycatsが指摘しているように、元のバグレポートは有効です。
これを修正することは有効なビルドを持つために重要であり、私はすべての利害関係者を満足させる解決策を考え出すことを意図して問題を再開します。

@wycats

より正確に言うと、私の意見では、期待されるセマンティクスは次のとおりです。

• package.jsonが最後にyarn.lock変更されてから変更されていない場合、 yarn.lockが真実のソースであり、更新しないでください。
• 場合package.json 、最後の時間以降に変更されたyarn.lock変更、更新yarn.lock満足そうpackage.jsonおよび更新node_modules 。
• yarn updateが実行されている場合は、すべての依存関係を再解決し、 package.jsonを満たすすべての最新バージョンを取得します。

つまり、リポジトリが最初にマシンにyarn.lockがチェックインされた場合、yarnは常にそれを信頼できる情報源として扱い、 yarn.lock更新を生成せず、ジャンプする必要があります。フェッチステップに直接。

これらは、＃364で追加したセマンティクスです。

@bestanderあなたは、これらのヒューリスティックを

この問題は非常に広範囲であり、 --pure-lockfileがデフォルトにならないことにすでに同意しており、@ wycatsで概説されているヒューリスティックに従います。 この問題を未解決のままにする場合は、タイトルにこの動作に関する現在の問題を反映させる必要があります。

@kittensは良さそうです、問題を更新します。
または、package.jsonが変更されなかったときに、ロックファイルを変更してインストールに関連する新しいものを開く必要があるかもしれません

新しい問題に移ることはできますか？ ここでのこのコメントは、アーカイブとして保存することができます

@thejameskyle 、いいですね。今日は新しい問題を作成して、ここにリンクします。

新しい焦点を絞った問題を作成しましたhttps://github.com/yarnpkg/yarn/issues/1576

package.jsonのパッケージがyarn.lockにない場合、 yarn install失敗させるオプションがあると興味深いでしょう。 パッケージがロックされていない場合は失敗します

上記を読んだ後もまだあいまいな説明を追加します。

tldr; package.json無関係な変更は、変更されていないpackage.jsonセンバーと互換性のある最新バージョンにパッケージを更新しません。

上記の文言のいくつかに基づいて、 yarn.lockがpackage.jsonハッシュにキー設定されてキャッシュされたように聞こえたため、 yarn.lockが書き込まれるように聞こえました（更新/キャッシュが無効になりました） ）への変更にpackage.json無関係な変化が問題となる、（すなわち、への更新"description"または他の依存性）は、その依存関係の可能性がありますyarn.lockに更新するバージョンを同じ既存のpackage.jsonセンバー内の新しいバージョン。

ただし、パッケージのyarn.lockエントリは、対応するpackage.json semverが更新された場合にのみ書き込まれることを確認しました（新しいsemverが既存のyarn.lockバージョンと互換性がある場合でも）。結果として、他の方法ではバージョンの更新は必要ありません）。

例えば、

• yarn add lodash@^4.17.1が[email protected]インストールするとします
• 後で、 [email protected]が利用可能になります。
• ヤーンは引き続き[email protected]をインストールします
• lodashのバージョンがpackage.json変更されない限り/ （またはyarnの追加/アップグレード/削除がlodashに対して特別に実行されるまで）。

ブレッドクラム＃1576

ところで、あなたがこのような小さな記事でドキュメントに貢献することをいとわないなら、それはコミュニティにとって素晴らしいでしょう。
コアチームはすべて問題の修正と新機能の追加に忙しく、コミュニティがドキュメントの維持を支援してくれることが期待され、高く評価されています。

@CrabDudeあなたの説明を共有してくれてありがとう。

上記の例では、 lodashとそれ自体の依存関係のみがyarn.lock更新されるという意味ですか？ たとえば、別の依存関係に新しいロックバージョンが含まれているがある場合でも、同時に更新されませんか？

または2番目の例： yarn.lockが大幅に古くなっており、ユーザーがyarn addを実行してpackage.jsonに新しい依存関係を追加するとします。 他のすべての古いパッケージはyarn.lockで更新されますか、それとも同じままですか？

@rarkins

上記の例では、lodashとそれ自体の依存関係のみがyarn.lockでロックバージョンを更新することを意味しますか？

はい。 これは私の例では支持されているようです。

他のすべての古いパッケージはyarn.lockで更新されますか、それとも同じままですか？

パッケージの非lodash依存関係ツリー/ロックエントリは更新されないようです。 lodashのサブ依存関係のみになります。

私の観点からは、これらのそれぞれが望ましいものであり、期待されています。

序文：私は毛糸が大好きです。 しかし、それは私を際限なく苛立たせます。

私の会社では、 yarn install決して変えないにも関わらず、常に異なるマシン間でロックファイルを（それぞれが同じバージョンを実行している）に変更package.json 。 その場合、 yarn addを使用して更新します。 CIは、ビルド後にgitステータスがクリーンであることを確認して、ロックファイルのチェックインなどを忘れずに確認し、頻繁に変更されるため、これは煩わしいことです。

私のyarnの期待は、_デフォルトで_すべてのマシンで同一のnode_modulesを保証することでした。 追加のフラグはありません。 利便性よりも正確さを優先します。 不確実性が必要な場合は、npmを直接使用できます。 ファイルが変更されたとき、それは何かがそれを変更したという私への合図であり、私はそれを精査する必要があります。 変わらないはずです。

質問

• ロックファイルが変更されても、node_modulesの内容は常に生成されたときと同じになると言われていますか？ 私はこれが事実であるとは思わないが、もしそうなら、私はこのスレッドの混乱を理解している-それはそうではないように見えるにもかかわらず、糸が正しいことをすることを意味するだろう。
• package.jsonが変更されると、ロックファイルが再生成されます。 その特定のプログラマーのnode_modulesの状態に応じて、意図せずに多くの依存関係を変更できませんでしたか？ Yarnはデルタを決定し、既存のロックを可能な限り保持するように努める必要があります（まだ保持していない場合）。
• なぜないyarn addでバージョンを指定package.jsonと^ ？ 繰り返しになりますが、yarnの約束は依存関係を凍結することであると理解しました。

関連するバグ

• node_modulesでランダムなパッケージが削除されると、 yarn installは再インストールせずに成功したことを示します。 それらの多くがなくなったとき、それはそれらを再インストールします。 npmは、この点でもう少し徹底的です。
• node_modulesを削除してクリーンインストールを実行すると、ロックファイルが再生成される傾向があります（これは、文字通り、期待するものとは逆です。ロックファイルにあるものを正確にインストールし、他には何もしないと思います）。
• パッケージに触れずにロックファイルを削除するか、クリーンインストール後にnode_modulesを削除すると、yarnはロックファイルを再生成し、通常は以前のバージョンとは大きく異なります。 これは、何も変更しないにもかかわらず、実行するたびに異なるコードを生成するコンパイラのようなものです。

全体として、yarnはインストールを高速化しますが、その核となる（機能しない）能力で失敗するようです。デフォルトでは、バージョンを一貫してフリーズします。 プロジェクトを開始するのに役立つ便利さは必要ありません。何年にもわたって巨大なチームでプロジェクトを維持するのに役立つ必要があります。 プログラマーは賢くて意図的です。変更が必要な場合は、明示的に質問します。

絶えず変化するロックファイルは自信を植え付けるものではなく、常に面倒です。 package.jsonがロックファイルと一致しない、ロックファイルがnode_modulesと一致しない、ロックされたバージョンが存在しないなどの警告とエラーが望ましいので、ビルドがトラックで停止します。依存関係について意図的に決定します。

@jspiro 、これを書いてくれてありがとう。
ここで提起されたいくつかの問題があります。
各号を個別に開くことをお勧めします。そうしないと、コメントで失われます。

最新バージョンのYarnを使用していますか？
0.18〜0.19の時点では、マシン間でyarn.lockファイルに変更はありません。

質問：

ロックファイルが変更されても、node_modulesの内容は常に生成されたときと同じになると言われていますか？ 私はこれが事実であるとは思わないが、もしそうなら、私はこのスレッドの混乱を理解している-それはそうではないように見えるにもかかわらず、糸が正しいことをすることを意味するだろう。

開発とオプションの依存関係は、同じロックファイルに対して省略できます。
ただし、プラットフォーム固有のパッケージを除いて、インストールされているものでは、node_modulesは同じ場所に同じパッケージを持っている必要があります。

package.jsonが変更されると、ロックファイルが再生成されます。 その特定のプログラマーのnode_modulesの状態に応じて、意図せずに多くの依存関係を変更できませんでしたか？ Yarnはデルタを決定し、既存のロックを可能な限り保持するように努める必要があります（まだ保持していない場合）。

それは素晴らしい機能リクエストです。そのためのPRを見てみたいです。

なぜyarnaddはpackage.jsonに^で指定されたバージョンを追加するのですか？ 繰り返しになりますが、yarnの約束は依存関係を凍結することであると理解しました。

これはnpmの動作を反映しています。
正確なバージョンについては、 yarn add [email protected]またはyarn add is-array --exactを実行できます。
たぶん、ある時点で正確なバージョンをデフォルトにする必要があります。これはRFCでの議論になる可能性があります。

node_modulesでランダムなパッケージが削除されると、yarninstallは再インストールせずに成功を示します。 それらの多くがなくなったとき、それはそれらを再インストールします。 npmは、この点でもう少し徹底的です。

ヤーンはデフォルトでクイックシャローチェックを実行します。
より詳細なチェックを行うと遅くなりますが、現在取り組んでいます。どのようにして迅速な詳細チェックを行うことができるかを考えています。
ただし、node_modules内のファイルに触れることは想定されていませんが、各ファイルの変更を確認すると、インストールエクスペリエンスが非常に遅くなります。
浅いチェックをスキップしたい場合は、インストールする前にnode_modules/.yarn-integrityファイルを削除してください。 これは公式ではなく、変更される可能性があります。
公式の方法はyarn install --forceを実行することです。これは完全インストールを強制しますが、副作用としてyarn.lockを書き換えます。

node_modulesを削除してクリーンインストールを実行すると、ロックファイルが再生成される傾向があります（これは、文字通り、期待するものとは逆です。ロックファイルにあるものを正確にインストールし、他には何もしないと思います）。

しばらくこれを見ていません。
問題を開いて、これを再現できるかどうかを確認してください。

クリーンインストール後にpackageまたはnode_modulesに触れずにロックファイルを削除すると、yarnはそれを再生成し、通常は以前のバージョンとは大きく異なります。 これは、何も変更しないにもかかわらず、実行するたびに異なるコードを生成するコンパイラのようなものです。

しばらくすると、推移的な依存関係の新しいバージョンがリリースされた可能性があります。
そのため、巻き上げロジックにより、node_modulesの構造が大幅に変更される可能性があります。
それは設計どおりに機能します。
https://github.com/yarnpkg/yarn/pull/2580に来るimportコマンドがあります。
これにより、既存のnode_modulesからロックファイルを生成できます。

@ jspiro 、Yarnは若いコミュニティ主導のプロジェクトです。それをより良く機能させるためのPRを歓迎します。

少なくとも、望ましいデフォルトの動作を設定するオプションを取得するチャンスはありますか？

現在、この問題を修正していますhttps://github.com/yarnpkg/yarn/issues/3490、$＃$ yarn installによってロックファイルが最適化されることがありますが、これは予期しない動作であり、修正します。
これが、この変更を要求する理由である可能性があります。そうでない場合、yarn.lockファイルは、package.jsonに手動で変更を加えた場合にのみ変更する必要があります。

.yarnrcで--pure-lockfile / -frozen-lockfileをtrueに設定すると、デフォルトでインストールコマンドに追加されます。

--install.pure-lockfile true

私の問題は、pure-lockfileを使用しないと、間違ったバージョンの依存関係がインストールされることです。 不要なyarn.lockの変更とは関係ありません

再現手順に関する問題を提出できますか？
整理します

開発者がyarn addではなくnpm install --saveを介して依存関係を誤って追加したために、 package.jsonとyarn.lockが同期しなくなったときにも、私はこれに噛まれました。

pure-lockfileをデフォルトにする必要があることに同意せず、 frozen-lockfileをyarn installのデフォルトにする必要があると主張します。

frozen-lockfileは、 yarn.lockとpackage.jsonが同期していない場合、エラーメッセージを生成します。 したがって、 frozen-lockfileは、ビルドマシン（つまり、ジェンキンス）で非常に役立ちます。これは、予想どおり、これらのビルドを失敗としてマークするためです。

次に、package.json /yarn.lockに追加するバージョンを決定するのは開発者の責任です。

残念ながら、デフォルトのyarn installは、まだロックされていない依存関係の最新バージョンをフェッチし、更新されたバージョンyarn.lockを書き込むだけで、プロジェクトの一部になることはありません。 したがって、予期しないバージョンのバンプによるビルドの将来の中断を許可します。 それが、私たちが最初にロックファイルを持っているまさにその理由です。

要点は次のとおりです。

add 、 remove 、 upgradeなどのコマンドのみがyarn.lockます。

installはそれを行う必要があります。つまり、依存関係をロックされたバージョンにインストールするか、 package.jsonとyarn.lock間に不一致が検出された場合は失敗します。 （唯一の例外は、そもそもyarn.lockがない場合です。その後、それが作成される可能性がありますが、二度と触れることはありません。）

したがって、frozen-lockfileは、ビルドが失敗するため、ビルドマシン（つまりjenkins）で非常に役立ちます。

CIモードになっていることを検出すると、これを自動的に有効にできると思いますか？

@BYKここに追加する前に、この問題が解決されたことに

新しいものを開くと思います☺️

私は@thejameskyleと@kittensに同意し、yarn.lockはpackage.jsonと自動的に同期する必要があります

これが言われたかどうかはわかりませんが、念のために：package.json内の何かが変更されたときにyarn.lock全体を無効にする必要はありません。 package.json内で変更されたパッケージのみの依存関係のみを無効にすることができます。 TypeScriptのみを更新した場合は、TypeScriptの依存関係を変更する必要があります（他の変更されていないパッケージを考慮して）。