Composerをこれから試そうと思っている人向けの文書です。
Composerって何？
ComposerはPHPプロジェクトの依存ライブラリを根こそぎvendor/以下にダウンロードしてくれるツールです。
詳しくは http://getcomposer.org/ を参照のこと。本家ドキュメントは超充実していますが、本家に和訳が無いせいか日本ではまだまだ普及段階といった印象です。
Composer用語のまとめ
- composer.json - そのプロジェクト自身の情報と、依存するライブラリ情報などを記述するJSON形式のファイル。これを元にComposerが仕事をする。
- package - トップディレクトリにcomposer.jsonが含まれているVCSリポジトリまたはzipファイル。
- Packagist - Composer用のpackage集約サイト。ここに登録されているpackageは短い名前でcomposer.jsonに記述できる。
開発者視点でのComposer+Packagistの良いところ
- 外部ライブラリ利用の精神的ハードルが下がる
- Composerがオートローダーを提供してくれるので、個別にrequire文を書いたりする手間が要らなくなる
- Symfony Componentsなどの巨大ライブラリへの抵抗感が薄れる
開発リーダー視点でのComposer+Packagistの良いところ
- 利用しているライブラリの出所が明らかになる
- 利用ライブラリのバージョンをそろえる方法が標準化できる
- 社内ライブラリを使うときなど、 git submodule を使ってウギャーってならずに済むかも
- 依存ライブラリ・ツールをプロジェクトごとにインストールできるので、システムグローバルにインストールされたもののバージョンの違いで悩まされる心配が減る
- 特にPHPUnitをComposer管理するのはオススメです。一部マシンに古いPHPUnitが入っていてテストが通らないという事件は過去のものになります。
ライブラリ作者視点でのComposer+Packagistの良いところ
- Packagistを使う場合はGitHubかBitBucketの利用がほぼ前提になっており、VCSだけで管理を完結させることができる
- GitHubのservice hookに対応しており、git pushするだけでPackagistにも変更が反映される
- 「v1.0.0」のようなtagを打てば、それがpackageのバージョン番号になる
- 安定版と開発版の管理もbranchやtagの操作で実現できる
packageの管理者がいちいちWebインターフェースを操作する必要がないのは良い仕組みだと感じます。残念ながら、packageの登録時だけはブラウザを開く必要があります。念のため。
その他文書へのリンク
- https://getcomposer.org/doc/ - 本家ドキュメント。PDFは100ページ超です。
- http://kohkimakimoto.github.io/getcomposer.org_doc_jp/doc/ - 本家ドキュメントを個人で和訳されている方がいらっしゃいます。まだ途中みたいですけど、続きも期待してます！