PHPパッケージ管理ツール「Composer」の処理の仕組みを見てみよう！

パッケージ管理ツール「Composer」

　今日では、多くのプログラミング言語において、開発プロジェクトにパッケージ管理ツールが欠かせないものとなりました。

　既存資産の活用で「車輪の再発明」を避け、開発の効率化を助けてくれます。また、セキュリティ意識が高まる中で、厳密なバージョン管理や確実なアップデートも強く求められています。使いやすいパッケージ管理ツールがなければ、いずれも頭の痛い問題になるのではないでしょうか。

　言語によってはパッケージ管理ツールを標準で提供されているものもある一方で、コミュニティ主導で3rdパーティツールとして提供されているものも多く存在しています。

　PHPでは、Composerがデファクトスタンダードなツールです。コミュニティ主導で開発されているものですが、PHPを利用するプロジェクトであれば、Composerの利用は不可欠になっているといえそうです。

　では、Composerはどのようにしてパッケージの存在を確認し、バージョンを解決するのでしょうか？ そんな疑問に答えるべく、一連の流れを追ってみようというのが本稿の主旨です。

　なお、内容はすべて執筆時点の最新版であるv2.8.2を前提としています。

composer.jsonとcomposer.lock

　多くの類似ツールと同様に、Composerでも「構成管理ファイル」「ロックファイル」によって依存パッケージを管理しています。

　前者にあたるのがcomposer.jsonで、後者がcomposer.lockというファイルです。それぞれの役割は次のとおりです。

• composer.json：プロジェクトが直接依存するパッケージ名と、許容するバージョンの範囲を指定。アプリケーション（プロジェクト）の開発者が設定するもの。パッケージの追加コマンド（composer require）によって更新される
• composer.lock：プロジェクトが間接的に依存するものも含めて、パッケージ名と詳細なバージョンを指定。Composerによって自動的に生成されるもの。追加済パッケージのバージョンアップ（composer update）によって更新される

　例えば、composer require "hoge/fuga:^1.0.0"と指定したら、パッケージhoge/fugaのバージョン1.x系統の最新版（例えば1.27.5）が利用されます。その際には、composer.jsonにはhoge/fuga:^1.0.0が、composer.lockにはhoge/fuga:1.27.5が記述されます。

　この例は、「自身が依存を持たない単一のパッケージの取得」という極めて単純なシナリオになっています。それでも、分解して捉えると複数の仕事が含まれていることに気付きます。

1. パッケージhoge/fugaが存在するか・利用可能かのチェック
2. hoge/fugaの利用可能なバージョンのチェック
3. バージョン解決の戦略^[1]に基づいて^1.0.0の条件に合致するバージョンの特定

　これに加えて、一般的なComposerの利用場面では、「間接依存を持つ場合」「複数パッケージ同士が同じパッケージに依存する場合」「インストールの前提条件が指定されている場合（PHPのバージョンや拡張の有無など）」等の更に複雑な要件が発生します。

　こうした問題は、どのように解決されているのでしょうか？ 具体的な仕組みを見ていきましょう。