composer.lockはバージョン管理にコミットする必要がありますか？

composer.lockリポジトリのあるアプリケーションでの使用とは少し混乱しています。

多くの人.gitignore composer.lockがリポジトリからはいけないと言っているのを見ました。

開発環境でライブラリを更新すると、新しいライブラリcomposer.lockができますが、本番環境に更新することはできませんか？

このファイルで競合が発生しませんか？

ライブラリを更新する場合は、ロックファイルもコミットする必要があります。これは基本的に、プロジェクトが使用しているライブラリの特定のバージョンにロックされていることを示しています。

変更をコミットし、誰かがコードをプルして依存関係を更新した場合、ロックファイルは変更しないでください。変更されている場合は、何かの新しいバージョンがあることを意味します。

リポジトリに置くと、各開発者が同じバージョンを使用していることが保証されます。

アプリケーション/プロジェクトの場合：間違いなくはい。

作曲のドキュメントは（強調して）この上で述べて：

アプリケーションのcomposer.lockを（composer.jsonとともに）バージョン管理にコミットします。

@mezaが言ったように：ロックファイルをコミットして、あなたと共同編集者が同じバージョンのセットで作業するようにして、「でも、私のコンピューターでは機能した」というような発言を防ぐ必要があります。;-)

ライブラリの場合：おそらくそうではありません。

この問題に関する作曲家のドキュメンテーションノート：

注：ライブラリの場合、ロックファイルをコミットすることは必ずしも推奨されません（...）

そしてここに述べる：

ライブラリについては、必要に応じてcomposer.lockファイルをコミットできます。これは、チームが常に同じ依存バージョンに対してテストするのに役立ちます。ただし、このロックファイルは、それに依存する他のプロジェクトには影響を与えません。メインプロジェクトにのみ影響します。

図書館については、@ Josh Johnsonの回答に同意します。

いくつかのプロジェクトで両方の方法を実行した後の私のスタンスはcomposer.lock、プロジェクトの一部としてコミットすべきではないということです。

composer.lockプロジェクトの一部ではないビルドメタデータです。依存関係の状態は、バージョン管理の方法（手動または自動ビルドプロセスの一部として）によって制御する必要があり、依存関係を更新してロックファイルをコミットする最後の開発者が勝手に決める必要はありません。

composerの更新間で依存関係が変化することを懸念している場合は、バージョン管理スキームに自信がありません。バージョン（1.0、1.1、1.2など）は不変である必要があり、初期の機能開発以外で「dev-」および「X. *」ワイルドカードを使用しないでください。

依存関係バージョンは暗黙的に定義されるようになったため、ロックファイルをコミットすることは、依存関係管理システムにとって退行です。

また、プロジェクトを再構築したり、依存関係を各環境（特にprod）で再取得したりする必要はありません。成果物（tar、zip、phar、ディレクトリなど）は不変であり、環境を変更することなくプロモートする必要があります。

1. プロダクションで依存関係を直接更新しないでください。
2. composer.lockファイルをバージョン管理する必要があります。
3. 実際の依存関係をバージョン管理するべきではありません。

1.依存関係をProductionに直接更新しないでください。これがコードの安定性にどのように影響するかがわかりません。新しい依存関係で発生するバグがある可能性があります。コードの動作が独自のものに影響を与える可能性があります。他の依存関係との互換性がない可能性があります。これは、適切なQAと回帰テストなどに従って、開発環境で行う必要があります。 。

2. composer.lockファイルのバージョン管理を行う必要があります。これは、依存関係に関する情報と、コードの現在の状態を複製できるようにする依存関係の依存関係に関する情報を格納するためです。すべてのテストと開発は特定のコードに対して行われたため、これは重要です。あなたが持っているコードの実際のバージョンを気にしないことは、アプリケーションにコードの変更をアップロードしてそれらをテストしないことに似ています。依存関係のバージョンをアップグレードする場合、これは喜んで行動する必要があり、すべてが引き続き機能することを確認するために必要な注意を払う必要があります。以前のリリースバージョンに戻すために1〜2時間のアップタイムを失うと、多大な費用がかかる可能性があります。

composer.lockを必要としないことに関して表示される引数の1つは、composer.jsonファイルで必要な正確なバージョンを設定できることです。これにより、誰かが実行されるたびに同じバージョンcomposer installがインストールされます。コード。これは真実ではありません。依存関係には独自の依存関係があり、その構成はサブバージョンまたはバージョン全体への更新を許可する形式で指定されている可能性があるためです。

あなたがあなたでLaravel 4.1.31をすることを指定しても、この手段composer.json、その中Laravel composer.jsonの 2 *：ファイルsymfonyのイベントディスパッチャとして必要な独自の依存関係を持っているかもしれません。この種の構成では、Symfonyのイベントディスパッチャー2.4.1を備えたLaravel 4.1.31で終わる可能性があり、チームの他の誰かがイベントディスパッチャー2.6.5を備えたLaravel 4.1.31を備えている可能性があります。 composerインストールを最後に実行したときでした。

したがって、バージョンシステムにcomposer.lockファイルがあると、このサブ依存関係の正確なバージョンが保存されます。そのため、チームメイトがcomposerをインストールすると、これがcomposerに基づいて依存関係をインストールする方法になります。ロック）あなたは両方とも同じバージョンを取得します。

更新したい場合はどうなりますか？次にcomposer update、開発環境で次のコマンドを実行します。これにより、新しいcomposer.lockファイルが生成され（何か新しいものがある場合）、テストした後、QAテストと回帰テストなどでテストされます。アップグレードしても安全なので、他のすべての人が新しいcomposer.lockをダウンロードするようにプッシュできます。

3.実際の依存関係をバージョン管理しないでください。意味がありません。ではcomposer.lockあなたは依存関係の正確なバージョンをインストールすることができますし、それらをコミットする必要はありません。それらを更新することになっていないのに、依存関係の10000ファイルをリポジトリに追加するのはなぜですか。これを変更する必要がある場合は、フォークして変更を加えてください。また、ビルドまたはリリースのたびに実際の依存関係を取得する必要がある場合は、composerでこの問題、キャッシュ、zipファイルなどを緩和するさまざまな方法があります。

次に、composer.jsonをプロジェクトにコミットすると、チームの他の全員がcomposer installを実行してプロジェクトの依存関係をインストールできます。

ロックファイルの目的は、インストールされた正確なバージョンを記録して、再インストールできるようにすることです。これは、バージョン仕様が1. *で、同僚が1.2.4をインストールするcomposer更新を実行してからcomposer.lockファイルをコミットする場合、composerをインストールすると、1.2.4も取得されることを意味します。 1.3.0がリリースされた場合。これにより、プロジェクトで作業しているすべての人が同じ正確なバージョンを持つことが保証されます。

つまり、composerのインストールが最後に行われてからコミットされている場合、ロックファイルがないと、新しいサードパーティのコードがプルダウンされます。

繰り返しになりますが、コードの破損を心配している場合、これは問題です。そして、それがComposerをcomposer.lockファイルを中心として考えることが重要である理由の1つです。

出典：作曲：それのすべてのロックファイルについて。

アプリケーションのcomposer.lockを（composer.jsonとともに）バージョン管理にコミットします。installコマンドはロックファイルが存在するかどうかをチェックし、存在する場合は、そこに指定されたバージョンをダウンロードするため、これは重要です（composer.jsonの内容に関係なく）。これは、プロジェクトを設定した人は、まったく同じバージョンの依存関係をダウンロードすることを意味します。CIサーバー、プロダクションマシン、チーム内の他の開発者、すべて、そして全員が同じ依存関係で実行されるため、デプロイメントの一部にのみ影響するバグの可能性が軽減されます。単独で開発した場合でも、プロジェクトを再インストールする6か月後には、依存関係がその後多くの新しいバージョンをリリースしたとしても、インストールされた依存関係が引き続き機能していると確信できます。

出典：Composer-Basic Usage。

コードの破損が心配な場合はcomposer.lock、バージョン管理システムにをコミットして、すべてのプロジェクトの共同編集者が同じバージョンのコードを使用していることを確認してください。ロックファイルがないと、新しいサードパーティのコードが毎回プルダウンされます。

例外は、インストール時に依存関係を更新する必要があるライブラリ（Zend Framework 2 Skeleton Appなど）のメタアプリを使用する場合です。したがって、目的は、開発を開始するたびに最新の依存関係を取得することです。

^{ソース：Composer：ロックファイルのすべて}

参照：composer更新とcomposerインストールの違いは何ですか？

これに対する正確な答えはありません。

一般的に言って、composerはビルドシステムが意図していることを行うべきではなく、VCSにcomposer.lockを置くべきではありません。Composerは、奇妙に逆に持っているかもしれません。プロデュースではなくエンドユーザーがロックファイルを使用するべきではありません。通常、ビルドシステムは、毎回空のディレクトリではなく、スナップショット、再利用可能なディレクトリなどを保持します。libをcomposerからチェックアウトする人々は、そのlibがロックを使用することを望んでいる可能性があります。これにより、libがロードする依存関係がテストされます。

一方、バージョン管理の負担が大幅に増加します。依存関係が厳密にロックされるため、ほぼ確実にすべてのライブラリの複数のバージョンが必要になります。すべてのライブラリのバージョンがわずかに異なる可能性がある場合は、複数のライブラリバージョンのサポートが必要です。また、必要な依存関係のサイズをすばやく確認することもできるので、そのままにしておくことをお勧めします。

これを実装すると、ロックファイルがライブラリまたは独自のワークディレクトリのどちらにも役立つとは思えません。ビルド/テストプラットフォームでのみ使用されます。これは、外部から取得したアセットを保持し、要求された場合にのみ更新し、テスト、ビルド、およびデプロイ用の反復可能なビルドを提供します。これはVCSで保持できますが、常にソースツリーで保持されるわけではありませんが、ビルドツリーはVCS構造の別の場所にあるか、別のシステムによって別の場所で管理されます。それがVCSに保存されている場合、ソースツリーと同じリポジトリに保持するかどうかは議論の余地があります。そうしないと、プルするたびに大量のビルドアセットがもたらされる可能性があるためです。私は、本番/機密の資格情報と膨張を除いて、すべてを整然としたレポに入れるのがとても好きです。

SVNは、リポジトリ全体を取得することを強制しないため、gitよりも優れています（実際にはgitに厳密に必要ではないが、そのサポートは制限されており、一般的には使用されていません）。単純なビルドリポジトリは、通常、ビルドツリーをマージ/エクスポートするオーバーレイブランチにすぎません。一部の人々は、ソースツリーで外部リソースを組み合わせるか、さらに外部、ビルド、ソースツリーを分離します。通常、ビルドキャッシングと繰り返し可能なビルドの2つの目的を果たしますが、少なくともある程度のレベルでそれを分離しておくと、フレッシュ/ブランクビルドと複数のビルドが容易になります。

これには多くの戦略があり、ソースツリーで外部ソースを維持しない限り、ソースリストの永続化で特にうまく機能するものはありません。

彼らはファイルのハッシュのようなものも持っていますが、2人がパッケージを更新するときにどのようにマージしますか？それだけでは、おそらくこれは誤解されていると思うはずです。

人々がロックファイルについて提唱している議論は、問題について非常に具体的で限定的な見方をしたケースです。再現可能なビルドと一貫したビルドが必要ですか？VCSにベンダーフォルダーを含めます。次に、アセットのフェッチを高速化し、ビルド中に破損した可能性のある外部リソースに依存する必要がないようにします。私が作成するビルドパイプラインとデプロイパイプラインは、どうしても必要な場合を除き、外部アクセスを必要としません。外部リソースを更新する必要がある場合、それは一度だけです。Composerが達成しようとしていることは、前述の場合を除いて、分散システムにとって意味があります。これは、一般的なクラッシュと更新が最も遅いパッケージの更新と同じくらい遅いライブラリ更新のライブラリ依存関係の地獄に終わるため、意味がありません。

さらに、私は猛烈に更新します。開発するたびに、すべてを更新してテストします。重要なバージョンのドリフトが潜入する非常に非常に小さなウィンドウがあります。現実的には、Composerの傾向があるセマンティックバージョニングが維持されている場合でも、多くの互換性の問題や破損があるとは限りません。

composer.jsonには、必要なパッケージとそのバージョンを入れます。そこでバージョンをロックできます。ただし、これらのパッケージにはcomposer.jsonによってロックされない動的バージョンとの依存関係もあります（バージョンロックを希望する場合、パッケージを自分で配置できなかった理由はわかりません）。ロックなしで何か違うものを取得します。あなたはそれについてあまり気にしないかもしれませんし、気にするかもしれません、それは依存します。気にしますか？おそらく少なくとも少しは、どのような状況でも潜在的な影響を確実に認識するのに十分ですが、常に最初にDRYを実行し、更新されたものを修正するだけの時間がある場合も、問題ではない可能性があります。

面倒な作曲家は時々そこにないだけで回避しようとしています、そして作曲家ロックファイルを持っている面倒は重要です。ビルドアセットとソースアセット（VCSで別々に結合するかどうか）に関して何をすべきか、またはすべきでないかをユーザーに伝える権利はまったくありません。それは彼らのビジネスではないため、あなたや私の上司ではないからです。「作曲家は言う」は権威ではありません。彼らはあなたの上司ではなく、この主題について誰にも優越感を与えません。あなただけがあなたの実際の状況とそのために何が最善かを知っています。しかし、彼らは物事がどのように機能するかを理解していないユーザーのためにデフォルトの行動方針を助言するかもしれません、その場合あなたはそれに従いたいかもしれませんが個人的には私はそうは思いません ' 物事がどのように機能するかを知り、要件を適切に解決できるようにするための真の代用品です。結局のところ、その質問に対する彼らの答えは、最良の推測です。composerを作成する人々は、composer.lockをどこに保持すべきか、またどこに保持すべきかわかりません。彼らの唯一の責任は、それが何であり、何をするかをあなたに伝えることです。それ以外の場合は、自分にとって最適なものを決定する必要があります。

composerはロックとJSONのどちらを使用するかについて非常に秘密にされており、両方を一緒に使用することが常に適切であるとは限らないため、ロックファイルを保持することは使いやすさに問題があります。installを実行すると、ロックファイルのみが使用されるため、表示されるため、composer.jsonに何かを追加すると、ロックされていないため、インストールされません。json / lockファイルに関して、実際にどのような操作が行われていて、何をしているのかが直感的ではなく、意味をなさないように見えることもあります（インストールはパッケージ名をとるのに役立ちますが、それを使用しようとすると、「いいえ」と表示されます）。

ロックを更新する、または基本的にjsonからの変更を適用するには、updateを使用する必要があり、すべてを更新したくない場合があります。何をインストールするかを選択するには、ロックが優先されます。ロックファイルがある場合は、それが使用されます。更新をいくらか制限することができますが、システムはまだ混乱しています。

更新には時間がかかります。RAMのギグです。また、しばらくの間触れられていないプロジェクトを、それが持っているバージョンから調べたものをピックアップした場合にも、おそらく時間が経つにつれて多くなり、おそらくそれを絞めるだけでは効率的には行われないと思います。

コンポジットであるとは期待できなかった秘密のコンポジットコマンドを持つことについては、非常に卑劣です。デフォルトでは、composer removeコマンドは、たとえばcomposer updateおよびcomposer removeにマップされるように見えます。

あなたが本当に尋ねる必要がある質問は、ソースツリーにロックを保持するべきかどうか、あるいは何らかの方法でそれをどこかに永続化するべきかどうかではなく、実際に何をするべきかを尋ねるべきです、あなたは自分で決めることができますそれを永続化する必要があるときと場所。

ロックを取得する機能があることは、堅牢な外部依存関係の永続化戦略がある場合に非常に便利です。これは、そのロック（発生元）の追跡と更新に役立つ情報を追跡しますが、そうでない場合そして、それはここにもそこにもありません。ソースツリーを汚染するための必須のオプションとして喉を強制された場合は、役に立ちません。これは、実際に適用されていないcomposer.jsonに多くの変更が加えられており、composerを使用しようとすると壊れてしまうレガシーコードベースで見られることは非常に一般的です。composer.lockはなく、同期の問題もありません。

はい、明らかに。

これは、ローカルにインストールされたcomposerがcomposer.jsonよりもcomposer.lockファイルを優先するためです。

vcsでロックファイルが使用できない場合、composerはcomposer.jsonファイルをポイントして最新の依存関係またはバージョンをインストールします。

composer.lockファイルは、依存関係をより詳細に維持します。つまり、ソフトウェアに含めるパッケージのバージョンの実際のコミットを指します。したがって、これは、依存関係をより細かく処理する最も重要なファイルの1つです。