Yarn: .gitignoreにyarn.lockを入れる必要がありますか？

gitにください。

https://yarnpkg.com/en/docs/migrating-from-npmを参照して

yarnまたはyarn add <package>いずれかを実行すると、Yarnはパッケージのルートディレクトリ内にyarn.lockファイルを生成します。 このファイルを読んだり理解したりする必要はありません。npm代わりにYarnを使い始めると、 yarn.lockファイルは、あなたとまったく同じ依存関係を確実に取得します。

明確にするために、これはアプリケーションだけでなくライブラリにも当てはまります。 npm-shrinkwrap.jsonとは反対に、最上位プロジェクトのyarn.lockのみが使用されるからです。 したがって、 yarn.lockファイルとの依存関係の依存関係は、不要な重複を生成しません。 複雑な開発依存関係があり、ライブラリのすべての寄稿者に同じビルドとテストの構成を持たせたい場合、ライブラリに役立ちます。

これは正しいです？

@goenning
たぶん、yarn.lockファイルをリポジトリに置くことが常に最良のアイデアであるとは限りません。
たとえば、私はシノピアを使用しています。 したがって、私はカスタムnpmレジストリを持っています。 このレジストリは、主にプライベートモジュールがある他のプロジェクトに使用します。
しかし、パブリックプロジェクトをパブリック依存関係しかないgitリポジトリにプッシュすると、yarn.lockに依存関係への間違ったリンクがあり、CIシステムはプロジェクトのビルドに失敗します。
依存関係は私のローカルリポジトリを指しています。
これは、他の開発者が私のリポジトリのクローンを作成した場合にも発生する可能性があります。
gitignoreにyarn.lockファイルを配置する以外にこれを回避する方法はありますか？

また、事前認証されたnpmレジストリ（npmにプロキシするmygetなど）がある場合、 yarn.lockにはパッケージへの事前認証されたリンクがあり、これは重大なセキュリティ違反です🎉
これは、大きなフォントでどこかに文書化する必要があります。

@Pfeifenjoy npmの代わりにgitサブモジュールを使用してプライベートパッケージにリンクするとどうなりますか？
gitを使用すると、デプロイキーを使用してリポジトリにアクセスできます（ssh経由）

@beenotung gitを依存関係マネージャーとして使用するのはあまり好きではありません。なぜなら、それは非常に遅く、依存関係を解決したい方法で解決しないためです。私の意見では、すべての依存関係を1つのマネージャーに

また、参照している依存関係は、ローカルのsinopiaアカウントに保存されているため、（自分のプロジェクトだけでなく）すべてが異なるアドレスを取得します。 私のプロジェクトが依存しているすべてのノードモジュールをgitで参照するのは非常に面倒です。
さらに、yarn.lockファイルを削除する方が簡単です。

@Pfeifenjoy糸に何をさせたいかで矛盾がある可能性はありますか？ 他のインストールに依存関係があることを確認する方法を提供したい場合は、それを含めてください-意図したとおりに実行されています。 プライベートリポジトリとソースを取得する場合は、レポからのキーやソルトを特に無視するのと同じように、コードをどのように共有するかについて非常に注意する必要があります（プロジェクトのreadmeに関する警告、機能/プルリクエストを行います）。

認証されたソースへのアクセスがロックファイルに含まれていることをユーザーに警告するために、yarnが実行時に警告を出す可能性がありますが、これも機能要求です。

@thisolivierは合理的に聞こえます

ただのメモ。
https://github.com/yarnpkg/yarn/issues/3330のため、中国またはその他の制限区域に住んでいて、他のレジストリ（eq taobao）を使用してモジュールをビルドする場合は、 yarn.lockをに追加する必要があります。 .gitignoreを実行し、 package-lock = falseを.npmrcに書き込みます。

ここで、 yarn.lockをコミットしない理由：一部のモジュールにはネイティブの依存関係があり、一部のプラットフォーム（ yarn.lockが生成される場所とまったく同じプラットフォーム）でのみ機能します。
ユーザーを満足させ、バグのないインストールを維持するために、yarnを削除します-yarnがこれを解決するための明確なドキュメントを備えたソリューションを提供しない限り、私は同意します。
（常に開発者から実話を聞いてください）

また、それはあなたのコミットを本当に醜くします。

私はここで最も賛成されたコメントに同意しません：

•プロジェクトがnpmを使用している場合は、 package-lock.jsonをリポジトリにコミットし、 yarn.lockをgitignoreします。
•プロジェクトでyarnを使用する場合は、 yarn.lockをリポジトリにコミットし、 package-lock.jsonをgitignoreします。

つまり、常にyarn.lockをリポジトリにコミットする必要はあり答えるには、.gitignoreに追加することをお勧めします。

他の人がnpmの代わりにYarnを使い始めると、yarn.lockファイルは彼らがあなたとまったく同じ依存関係を取得することを保証します

まず、いいえ、そうではありません-パブリックnpmレジストリのみを使用している場合のみです。 さらに悪いことに、yarnでプライベート組織に認証されておらず（まだnpmにいる場合でも）、同じ名前のパッケージがパブリックレジストリに存在する場合、プロンプトなしで間違ったパッケージがインストールされます。 ヤーンがエラーなしでインストールされる理由は混乱しますが、ヤーンを使用するとアプリは機能しませんが、npmを使用すると機能します。

第二に、多くのコードベースはyarnを使用していません。 「いつ糸に切り替わるか」は問題ではありません。 ほとんどすべてのノードサービスと基本的なWebサーバーはnpmを使用しており、yarnに移行する予定はありません。 私はReactの糸が好きです、それだけです。

上記の@Pfeifenjoyのように：

カスタムnpmレジストリがあります。 このレジストリは、主にプライベートモジュールがある他のプロジェクトに使用します

しかし、パブリックプロジェクトをパブリック依存関係しかないgitリポジトリにプッシュすると、yarn.lockに依存関係への間違ったリンクがあり、CIシステムはプロジェクトのビルドに失敗します。

^もう1つ、ローカルで解決する場合でも、ソリューションをyamlまたはCIの構成や、アプリを起動する他の場所に組み込む必要があります-どのレジストリとどのコマンドをいつ使用するかを指示できるロジックのようなものです-迷惑で不必要に聞こえます

もう1つ、すべての人に常にyarn.lockをレポにコミットし、それを決して無視しないように勧めると、開発者はすでにnpmに大きく依存しているレポでyarnを使い始めるでしょう。 それが正常に機能する場合でも、2つのロックファイルに冗長性があり、依存関係地獄への扉が開かれます。 そして、あなたは何人かの開発者があなたの貢献グラフを台無しにするある時点で〜25kラインyarn.lockをコミットすることを知っています：joy：