パッケージ管理を理解する上で必要な登場人物の整理
まずは、Composerによるパッケージ管理を理解する上で欠かせない概念を整理します。最も重要なのが、パッケージとリポジトリです。
パッケージ
パッケージは、ライブラリやプロジェクトといったひとかたまりの単位をまとめるものです。名称や依存パッケージなどの情報を持ちます。1つのcomposer.json
で定義される範囲が、1つのパッケージに相当します。
開発作業を進めるプロジェクト自身に相当するパッケージは、特別に「ルートパッケージ」と呼びます。すなわち、composer install
などのコマンドで直接的に利用されるcomposer.json
が示すパッケージです。
ルートパッケージでは、パッケージの名称やバージョン情報の指定が必須ではありません。逆に、composer.json
で指定できる設定項目の中には、ルートパッケージでのみ利用可能な内容も存在します。
ルートパッケージにて依存として列挙されたパッケージ群もまた、それぞれcomposer.json
によって構成が定義されている訳です。それらを辿っていき、整合性をとるのがComposerの大きな仕事の1つと言えます。
リポジトリ
利用可能なパッケージやそのバージョンのリストを提供するのが、リポジトリです。大まかに言えば、「パッケージ名の一覧」「パッケージの各バージョンごとのcomposer.json
」の集合があるような存在です。
また、ここでは、パッケージ本体(バイナリやソースコード)の管理は行われません。その代わりに、それぞれのパッケージごとに本体の取得方法が記載されています。この情報を参考に、Composerが実際のファイルを取得しvendor
ディレクトリに展開していくことになります。
リポジトリには、3つのタイプが存在します。それぞれパッケージリストの提供方法が異なります。
- composer:パッケージリストや、単体のパッケージの存在有無を確認する方法を提供するサービスを利用する
- vcs:Gitのベアリポジトリなど、VCSを利用してパッケージをホストしているoriginサーバーを列挙しておく。社内公開しているパッケージの利用などに使われる
-
package:
composer.json
内に、パッケージのリストを明示的に列挙しておく。モノレポ構成の実現などに使われる
composerタイプのリポジトリは、独立したパッケージ管理提供の主体といえます。一方で、vcsタイプやpackageタイプは、ルートパッケージ内で自身に関わるパッケージに関する情報を管理する方法といえるでしょう。
Composerのリポジトリは、デフォルトではPackagistです。これはcomposerタイプのリポジトリで、問い合わせ先となるサービスURLがhttps://packagist.org/
となる設定です。
その他のリポジトリを利用するには、ルートパッケージのcomposer.json
のrepositories
フィールドに追記していくことになります。また、repositories
フィールドに"packagist.org": false
を設定することで、Packagistの無効化も可能です。
composerタイプの典型的な利用例はPackagistですが、その用途は必ずしもそれだけに限ったものではありません。例えば、非公開のパッケージを管理するためのSaaSであるPrivate Packagistや、Satisによる自作リポジトリの生成・利用が考えられます。