あんまり知られてないけど有用な composer の機能
※ 下記の内容はすべて公式マニュアルに書かれています
※ 社内向けに書いたので若干整合性が怪しい
create-project
知られていないどころか超有名な機能ですが、尺稼ぎで create-project から。
フレームワークをいじってると
下記のコマンドでインストールします
composer create-project symfony/framework-standard-edition my_project_name
のような文言によく出くわします。
これがなにしてるかは http://qiita.com/DQNEO/items/74f4bb8fe447e4582a97 が詳しい。
要するに git で引っ張ってきてその中で composer install してるだけのようです。
使うことはあまりないと思うけど、覚えておくと便利。
autoloader-suffix
{
"config": {
"autoloader-suffix": "hoge"
}
}
のような指定をすると composer が生成するクラスローダ名を固定することが出来ます。
<?php
// autoload.php @generated by Composer
require_once __DIR__ . '/composer' . '/autoload_real.php';
return ComposerAutoloaderInit417b46943594f4f4c0f3cb6c377dd5ea::getLoader();
<?php
// autoload.php @generated by Composer
require_once __DIR__ . '/composer' . '/autoload_real.php';
return ComposerAutoloaderInithoge::getLoader();
これで何が嬉しいかというと、リリース時の安心感が増える点です。
autoload.php が先に転送されてしまうと（たとえ些細な変更でも瞬間的に）「class not found」の嵐になってしまうので、固定するのはアリだと思います。
config/platform
{
"config": {
"platform": {
"ext-gd": "2.0.0"
}
}
}
のような指定をすると、「あたかも gd 2.0.0 が入っているかのように」依存関係を解決します。
つまり composer を騙すことが出来ます。
ライブラリの composer.json で require でエクステンションが書かれているが、その機能を一切使用しない時に有用です。
逆に言えば「なんかエラーが出るからとりあえず指定」程度の認識では使うべきではありません。
また
{
"config": {
"platform": {
"php": "5.3.0"
}
}
}
のようにすると php 自体のバージョンも騙せます。
「騙す」というと感じが悪いですが、依存関係も含めてすべて 5.3.0 として振る舞ってくれるので、別環境で composer.lock を吐いてる人は指定しても良いかもしれません。
例えば私は普段 Windows 機で開発をしていて、 composer install/update も Windows 上でやってしまうことが多いです。
しかし悲しきかな、私の Windows に入っている php は 5.5.9 です。案件が 5.5.9 とは限りません。
そんな時、案件に合わせた config/platform/php を指定することで依存関係を解決しています。
scripts
composer コマンド実行時のイベントをフックすることが出来ます。
https://getcomposer.org/doc/articles/scripts.md を読めとしか言いようが無いですが…。
イベントは大量にありますが、
| イベント名 | 実行タイミング |
|---|---|
| pre-install-cmd |
composer install コマンドの実行前 |
| post-install-cmd |
composer install コマンドの実行後 |
| pre-update-cmd |
composer update コマンドの実行前 |
| post-update-cmd |
composer update コマンドの実行後 |
だけ知っていればよろしいです。composer install/update の前後です。
似たようなものに pre-package-install ってのもありますが、これはパッケージ単位です。
require に書かれたパッケージ分実行されます。
なお、イベントは伝播しません（考えれば当たり前ですが）。
何かライブラリを作って scripts を指定したとしてもそれを使う側の親プロジェクトでは決して実行されないことに注意しましょう。
実は composer 内部にはフックスクリプト用のクラスがあり、かなり高度な事ができるのですが、ここに書く範囲を超えているので割愛します。
branch as 1.0
{
"require" : {
"vendor/product": "branch-name as 3.0.0"
}
}
とすると vendor/product の branch-name を「バージョン 3.0.0」だとみなしてくれます。
fork したプロジェクトでバージョンが切られていない場合などに使えると思います。
ただし、その場合はどう考えても黒魔術的（前後関係から考えて、fork 先でバージョンが切られていない状況はほぼあり得ない）であり、実験的に使うのが良さそうです。