なぜ、composerは2つのファイル（composer.jsonとcomposer.lock）で動作するように設計されたのですか

Question

私自身のパッケージマネージャを作成し、現在既存のソリューションを見直したいと思います。

は、私は今、PHPの作曲で遊んだ、と二つのファイルがあることは非常に驚くべきことであった：正確な固定のためのプロジェクト構成のための

• composer.json、および非固定の依存関係

• composer.lockを依存関係

私は従属関係をピンする必要がある理由を理解しています。.lockそれ自体で形成することは私にとって論理的なようです。

プロジェクトメタデータが2つのファイルに分割されている理由はわかりません。

誰も説明することができます、なぜこのように設計されたのですか？ composer.jsonでdepsを正しく固定できなかったのはなぜですか？

UPD。 http://doc.crates.io/guide.html#cargotoml-vs-cargolock

Answer 1

.lock情報が絶対的に固定され、一般的にjson情報に基づいてcomposer update要求によって作成：錆の貨物は、代わりに同じ2つのファイル構成を有し、かつ.lockファイルの意味の素敵な説明があり、判明しました。 ..しかし、開発者は必ずしもすべてを正確なバージョンに固定する必要はありません。.jsonファイルを使用しないと、依存関係のすべてのバージョンをアップグレードするたびに.lockファイルを手動でアップグレードする必要があります。

.jsonファイルのみ即時依存関係を保持しているのに対し、.lockも...依存関係の依存関係、および依存関係の依存関係の依存関係などを保持している....と開発者として、あなただけのあなたの直接の依存関係を管理する必要がある必要があり、あなたがjsonに対してアプリケーションを構築するが、開発時.lock

Answer 2

に対して展開する必要があり、これらのライブラリは

基本的には自分の.jsonファイルを経由して、独自の依存関係を制御することを可能にするには、通常にアップグレードできるようにしたいです最新のcompatib依存関係の簡単なバージョンです。 composer.jsonには、依存関係と互換性のあるバージョンに関する情報があります。 composer.lockには互換性情報がないため、パッケージが2.2.7の依存関係に対してビルドされていると言えるかもしれませんが、そのバージョン> = 2.1とそのような依存関係の3が互換性があり、次のメジャーバージョンは安全であることが保証されていません。

テスト用またはリリース用にビルドする場合は、毎回まったく同じ依存バージョンのセットに対してビルドを行う必要があります。 composer.lockは、使用されている正確なバージョンを列挙することでそれを可能にします。依存関係の新しいバージョンが出てきたとしても、依存関係の固定は、依存関係のパッケージの変更による動作の変化を心配する必要がないように、ビルドが変更されないことを保証します。