composer.lockはバージョン管理に取り組むべきですか？
リポジトリを持つアプリケーションで使用されるcomposer.lockと少し混乱しています。
私たちはリポジトリから.gitignorecomposer.lockをするべきではないと多くの人が言っているのを見ました。
自分の開発環境で自分のライブラリを更新すると、新しいcomposer.lockができますが、それらを本番環境に更新することはできません。
このファイルで競合が発生しませんか。
ライブラリを更新した場合は、ロックファイルもコミットします。それは基本的にあなたのプロジェクトがあなたが使っているlibsのそれらの特定のバージョンにロックされていると述べています。
あなたがあなたの変更をコミットし、誰かがあなたのコードを引っ張り、依存関係を更新するなら、ロックファイルは変更されないはずです。それが修正された場合、それはあなたが何かの新しいバージョンを持っていることを意味します。
リポジトリに入れることで、各開発者が同じバージョンを使っていることが保証されます。
アプリケーション/プロジェクトの場合：はい。
作曲家のドキュメント はこれを（強調しながら）述べています。
アプリケーションのcomposer.lockを（composer.jsonと共に）バージョン管理にコミットします。
@mezaが言ったように：あなたとあなたの共同編集者が同じバージョンのセットに取り組んでいて、「しかしそれは私のコンピュータではうまくいった」というようなことができないようにロックファイルをコミットするべきです。 ;-)
ライブラリの場合：おそらくそうではありません。
作曲家のドキュメンテーションは、この問題について注意しています：
注：ライブラリの場合、必ずしもロックファイルをコミットすることをお勧めしません（...）
そしてここに と書いてあります ：
あなたのライブラリのためにあなたが望むならcomposer.lockファイルをコミットするかもしれません。これにより、チームは常に同じ依存関係バージョンをテストすることができます。ただし、このロックファイルは、それに依存する他のプロジェクトには影響しません。メインプロジェクトにのみ影響します。
図書館の場合、私は@Josh Johnsonの答えに同意します。
いくつかのプロジェクトで両方の方法でそれを行った後の私の考えは、composer.lockはプロジェクトの一部としてコミットされるべきではないということです。私はそうする方が簡単であることを知っていますが、私がこれについて訴訟を起こす間、私と一緒に耐えてください。
composer.lockはプロジェクトの一部ではないビルドメタデータです。依存関係の状態は、依存関係のバージョン管理方法（手動または自動ビルドプロセスの一部として）で制御する必要があります。依存関係を更新してロックファイルをコミットする最後の開発者によるものではありません。
あなたがあなたの依存関係が作曲家の更新の間で変わるのを心配しているならば、あなたはあなたのバージョン管理体系に自信がないのです。バージョン（1.0、1.1、1.2など）は不変でなければならず、最初の機能開発以外では "dev-"と "X. *"のワイルドカードを避けるべきです。
依存関係のバージョンは暗黙のうちに定義されるようになったため、ロックファイルをコミットすることは依存関係管理システムにとって後退です。
また、プロジェクトを再構築したり、各環境で依存関係を再取得したりする必要はありません（特にprod）。成果物（tar、Zip、phar、ディレクトリなど）は不変であり、状態を変えずに環境を介してプロモートする必要があります。
編集：これは一般的な答えにはならないことを知っていましたが、投票していただければ、理由を説明するのに十分親切になるでしょう答えの欠陥を指摘しているコメント？ありがとうございます。
- 依存関係を直接Productionに更新しないでください。
- あなたは composer.lock ファイルをバージョン管理するべきです。
- 実際の依存関係をバージョン管理しないでください。
1。依存関係を本番環境に直接更新しないでください。これがコードの安定性にどのように影響するかがわかりません。新しい依存関係でバグが導入されたり、コードがあなた自身に影響を与える方法を変えたり、他の依存関係との互換性がなくなったりする可能性があります。適切なQAや回帰テストなどに従って、dev環境でこれを行うべきです。 。
2。 composer.lock fileをバージョン管理する必要があります。これには、依存関係に関する情報と、コードの現在の状態を複製できるようにする依存関係の依存関係に関する情報が格納されています。テストと開発はすべて特定のコードに対して行われているため、これは重要です。あなたが持っているコードの実際のバージョンを気にしないことはあなたのアプリケーションにコード変更をアップロードしてそれらをテストしないことに似ています。依存関係のバージョンをアップグレードする場合は、これは意図的な行動であるはずです。また、すべてが依然として機能することを確認するために必要な注意を払う必要があります。以前のリリースバージョンに戻るまでに1〜2時間のアップタイムを失うと、多額の費用がかかる可能性があります。
composer.lock を必要としないという議論の1つは、 composer.json ファイルに必要なバージョンを正確に設定できることです。 composer installを実行すると、同じコードがインストールされます。あなたの依存関係はそれ自身の依存関係を持ち、それらの設定はsubversions、あるいはバージョン全体への更新を許すフォーマットで指定されるかもしれないので、これは本当ではありません。
つまり、 composer.json にLaravel 4.1.31が必要であると指定した場合でも、 composer.json ファイルにLaravelが含まれる可能性があります。 Symfonyのイベントディスパッチャとして必要な独自の依存関係：2. *。このような設定では、Symfonyのイベントディスパッチャー2.4.1ではLaravel 4.1.31になり、チームの他の誰かにevent付きLaravel 4.1.31を設定することができます。 -dispatcher 2.6.5、それはすべてあなたが作曲家のインストールを実行した最後の時であったかに依存するでしょう。
したがって、 composer.lock ファイルをバージョンシステムに格納すると、このサブ依存関係の正確なバージョンが格納されます。したがって、あなたとあなたのチームメイトがcomposerインストールを行うとき（これは依存関係をベースにしてインストールする方法です） composer.lock ）では両方とも同じバージョンになります。
あなたが更新したい場合はどうなりますか？それから、あなたの開発環境でcomposer updateを実行してください、これは新しい composer.lock ファイルを生成し（新しいものがあれば）、そしてあなたがそれをテストした後、そしてQAテストとリグレッションテストそれとものを作ります。アップグレードしても安全なので、他の人が新しい composer.lock をダウンロードするようにプッシュできます。
3。実際の依存関係をバージョン管理しないでください。意味がありません。 composer.lock を使えば、依存関係の正確なバージョンをインストールすることができ、それらをコミットする必要はありません。更新することが想定されていないのに、なぜあなたはあなたのレポに依存関係の10000ファイルを追加するでしょうか。あなたがこれの1つを変更する必要があるならば、あなたはそれをフォークしてそこであなたの変更を加えるべきです。ビルドやリリースのたびに実際の依存関係を取得しなければならないことが心配な場合は、composerにこの問題を軽減するさまざまな方法、キャッシュ、Zipファイルなどがあります。
あなたはそれから
composer.jsonをあなたのプロジェクトにコミットし、あなたのチームの他の誰もがあなたのプロジェクトの依存関係をインストールするためにcomposer installを実行することができます。ロックファイルのポイントは、再インストールできるようにインストールされている正確なバージョンを記録することです。つまり、バージョン仕様が1 *で、同僚が1.2.4をインストールするcomposer updateを実行してからcomposer.lockファイルをコミットすると、composerのインストール時にも1.2.4になります。 1.3.0がリリースされている場合これにより、プロジェクトに取り組むすべての人が正確に同じバージョンを持つようになります。
つまり、作曲家のインストールが最後に行われてから何もコミットされていなければ、ロックファイルなしで、新しいサードパーティコードがプルダウンされます。
繰り返しますが、これはあなたのコードが壊れるのを心配しているなら問題です。それが、Composerをcomposer.lockファイルを中心としたものとして考えることが重要な理由の1つです。
出典： 作曲者：ロックファイルについてのすべてです 。
アプリケーションのcomposer.lockを（composer.jsonと共に）バージョン管理にコミットします。 installコマンドはロックファイルが存在するかどうかをチェックし、存在する場合は（composer.jsonの指示に関係なく）そこに指定されたバージョンをダウンロードするので、これは重要です。つまり、プロジェクトを設定した人はだれでも、まったく同じバージョンの依存関係をダウンロードすることになります。あなたのCIサーバー、本番マシン、チーム内の他の開発者、すべての人、そしてすべての人が同じ依存関係で実行されているため、展開の一部にしか影響を及ぼさないバグの可能性が軽減されます。あなたが一人で開発していても、プロジェクトを再インストールする6か月以内に、あなたの依存関係がそれ以来多くの新しいバージョンをリリースしたとしても、インストールされた依存関係はまだ機能していると確信できます。
出典： 作曲家 - 基本的な使い方 。
コードの改ざんが心配な場合は、すべてのプロジェクト共同作業者が同じバージョンのコードを使用するように、composer.lockをバージョン管理システムにコミットする必要があります。ロックファイルがないと、毎回新しいサードパーティコードがプルダウンされます。
例外は、インストール時に依存関係を更新する必要があるライブラリであるメタアプリケーションを使用する場合です（ Zend Framework 2 Skeleton App のように）。そのため、開発を開始するたびに最新の依存関係を取得することを目的としています。
これに対する正確な答えはありません。
一般的に言って、作曲家はビルドシステムがすることを意図したことをしてはいけませんし、あなたはVCSにcomposer.lockを入れてはいけません。作曲家は奇妙にそれを逆に持っているかもしれません。エンドユーザーはプロデュースよりもロックファイルを使うべきではありません。通常、ビルドシステムは毎回空のディレクトリではなく、スナップショット、再利用可能なディレクトリなどを保存します。 libをロードする依存関係がテストされているように、人はcomposerからlibをチェックアウトして、そのlibにロックを使用させたいかもしれません。
その一方で、依存関係が厳密にロックされるため、ほぼ確実にすべてのライブラリの複数のバージョンが必要な場合は、バージョン管理の負担が大幅に増加します。すべてのライブラリがわずかに異なるバージョンを持つ可能性が高い場合は、いくつかのマルチライブラリバージョンのサポートが必要です。また、必要な依存関係のサイズをすぐに確認できます。
それを船上で考えてみると、ロックファイルがライブラリにも自分の作業ディレクトリにも役立つとは思われません。私が使用するのは私のビルド/テストプラットフォームに限られ、外部から取得したアセットは要求されたときにのみ更新され、テスト、ビルド、デプロイのための再現性のあるビルドが提供されます。これはVCSに保存することができますが、常にソースツリーと一緒に保存されるわけではありませんが、ビルドツリーはVCS構造内の別の場所にあるか、別の場所にある別のシステムによって管理されます。それがVCSに格納されている場合、それをソースツリーと同じリポジトリに保持するかどうかは議論の余地があります。そうしないと、すべてのプルが大量のビルドアセットをもたらす可能性があるためです。私は、プロダクションや機密性の高い資格情報と膨大なものを除いて、すべてが適切に配置されたレポに含まれているのがとても好きです。
SVNはリポジトリ全体を取得することを強制しないため、gitよりも優れています（ただし、gitには厳密には必要ありませんが、そのサポートは限られており、一般的には使用されません）。単純なビルドリポジトリは通常、ビルドツリーをマージ/エクスポートするためのオーバーレイブランチにすぎません。外部リソースをソースツリーに結合したり、さらに外部ツリー、ビルドツリー、およびソースツリーを分離したりする人もいます。それは通常2つの目的、ビルドのキャッシュと繰り返し可能なビルドを提供しますが、時々少なくともあるレベルでそれを別々に保つことはフレッシュ/ブランクビルドとマルチプルビルドを容易に可能にします。
これにはいくつかの方法がありますが、ソースツリーに外部ソースを保存しているのでない限り、それらのいずれも特にソースリストの永続化にうまく機能することはありません。
それらはファイルのハッシュのようなものも持っています、二人がパッケージを更新するときそれはどうやってマージしますか？それだけであなたは多分これが誤解されていると思わせるでしょう。
人々がロックファイルについて提唱している議論は、彼らが問題について非常に具体的かつ制限的な見方をした場合である。繰り返し可能なビルドと一貫したビルドが必要ですか。ベンダーフォルダをVCSに含めます。そうすれば、ビルド中に壊れた可能性のある外部リソースに頼る必要がなくなるだけでなく、資産の取得も高速化されます。どうしても必要な場合を除いて、私が作成したビルドおよびデプロイのパイプラインには外部アクセスが必要ありません。外部リソースを更新する必要がある場合、それは一度だけです。一般的な衝突を伴うライブラリの更新と、更新が最も遅いパッケージの更新と同じくらい遅い更新のためにライブラリの依存関係の地獄になってしまうので、作曲家が達成しようとしていることは意味をなさないことを意味しません。
さらに私は猛烈に更新します。開発するたびに、すべてを更新してテストします。重大なバージョンドリフトが潜入するための非常に小さなウィンドウがあります。現実的にも、セマンティックバージョニングが支持されているとき、それは作曲家のためにある傾向がある、あなたはその多くの互換性問題や破損を持っているとは思わない。
Composer.jsonに、必要なパッケージとそのバージョンを入れます。あなたはそこにバージョンをロックすることができます。ただし、これらのパッケージはcomposer.jsonによってロックされない動的バージョンとの依存関係もあります（ただし、バージョンロックされるようにしたい場合は自分で配置できない理由はわかりませんが）。ロックなしで何か違うものになる。あなたはそれについてあまり気にしないかもしれないか、気にするかもしれない、それは依存します。気にしますか？少なくとも少しは、どんな状況でも潜在的な影響を確実に認識するのに十分ですが、最初にDRYを実行して何かを修正する時間があれば、問題にならないかもしれません。それは更新されました。
面倒な作曲家は時にはそこにないだけで避けようとしています、そして作曲家ロックファイルを持つことができる面倒は重要です。ビルドアセットとソースアセットに関して（VCSで別のメンバーに参加するかどうかに関係なく）自分がすべきこと、すべきでないことをユーザーに教える権利は絶対にありません。 「作曲家が言う」は権威ではありません、彼らはあなたの優れた役員でもありませんし、彼らはこの主題に関していかなる優位性も誰にも与えません。あなただけがあなたの本当の状況とそれに最適なものを知っています。しかし、物事がどのように機能するのか理解していないユーザーには、デフォルトの行動方針を推奨することもありますが、個人的には、物事がどのように機能するのかを知ることに代わることはできません。あなたの条件を試しなさい。結局のところ、その質問に対する彼らの答えは最も良い推測です。作曲家を作る人々はあなたがあなたの作曲家をどこに保つべきかを知らない。彼らの唯一の責任はそれが何であるか、そしてそれが何をするかをあなたに言うことです。それ以外では、自分に最適なものを決める必要があります。
ロックファイルを保持するのは使い勝手の点で問題があります。なぜならcomposerはロックを使うのかJSONを使うのかについて非常に秘密にされていて、両方を一緒に使うのが必ずしも良いとは限らないからです。 installを実行するとロックファイルしか使用されないため、composer.jsonに何かを追加してもロックされていないためインストールされません。 json/lockファイルに関して、実際に何をしているのか、そして何をしているのかは、直感的に理解できないこともあります（installはパッケージ名を取りますが、使用しようとするとnoと表示されます）。 ）.
ロックを更新したり、基本的にJSONから変更を適用したりするには、updateを使用しなければならず、すべてを更新したくないかもしれません。何をインストールするべきかを選択するためにロックが優先されます。ロックファイルがある場合は、それが使用されているものです。更新を多少制限することはできますが、システムはまだ混乱しています。
更新には時間がかかります。あなたがそれがそれが持っているバージョンから見たそのしばらくの間触れられていないプロジェクトを選ぶなら、私も同様に疑う。
それはあなたがコンポジットであることを期待することができなかった秘密のコンポジットコマンドを持つことに関しては非常に卑劣です。デフォルトでは、composer removeコマンドは、たとえば、composer updateおよびcomposer removeにマップするように見えます。
あなたが本当に尋ねる必要がある質問はあなたがあなたのソースツリーのロックを維持するべきかどうか、あるいはあなたが何らかの方法でどこかにそれを持続させるべきかどうかではなくあなたが実際に何をするべきか尋ねるべきですそれを持続させる必要があるとき、そしてどこで。
ロックする能力を持つことは、それを追跡して更新するのに役立つ情報を追跡するので、堅牢な外部依存関係の永続化戦略を持っている場合には非常に便利です。それからそれはここにもそこにもない。それがあなたのソースツリーを汚染させるためにそれが必須の選択肢としてあなたののどを圧倒するときそれは役に立ちません。実際には適用されておらず、composerを使おうとすると壊れてしまうというcomposer.jsonに多くの変更を加えたレガシーコードベースを見つけることは非常に一般的なことです。いいえcomposer.lock、非同期の問題はありません。