実行時Composerユーティリティ
Composerはほぼプロジェクトに依存関係をインストールするのに使われますが、実行時に使える機能もいくつかあります。
特定のバージョンに於けるこれらの機能のどれかに依る必要があれば、composer-runtime-apiパッケージをrequireできます。
自動読み込み
自動読み込み器は最も使われるものであり、既に基本的な使い方の手引きで押さえられています。 全てのComposerのバージョンで使えます。
インストールされたバージョン
composer-runtime-api
2.0では、現在インストールされているバージョンを調べるための静的メソッドを提供する新しいComposer\InstalledVersionsクラスが導入されました。
Composerの自動読み込み器が含まれている限り、コードで自動的に使用できます。
このクラスの主な用例は以下の通りです。
パッケージX（あるいは仮想パッケージ）が存在するか見る
\Composer\InstalledVersions::isInstalled('vendor/package'); // 真偽値を返す
\Composer\InstalledVersions::isInstalled('psr/log-implementation'); // 真偽値を返す
Composer 2.1から、2つ目の引数に偽を渡すことによりrequire-devを介してインストールされたかを確認することもできます。
\Composer\InstalledVersions::isInstalled('vendor/package'); // このパッケージがインストールされていれば真を返す
\Composer\InstalledVersions::isInstalled('vendor/package', false); // vendor/packageがrequireにあれば真を、require-devにあれば偽を返す
なお、プラットフォームパッケージがインストールされているかどうかを確認するのには使えません。
パッケージXのバージョンYがインストールされているかどうかを見る
補足： これを使うためには
"composer/semver": "^3.0"をrequireしなければなりません。
use Composer\Semver\VersionParser;
\Composer\InstalledVersions::satisfies(new VersionParser, 'vendor/package', '2.0.*');
\Composer\InstalledVersions::satisfies(new VersionParser, 'psr/log-implementation', '^1.0');
例えば、vendor/packageについて、2.0.*に適合するバージョンでインストールされている場合だけでなく、与えられたパッケージ名が何らかの他のパッケージにより置き換えられていたり与えられていたりする場合にも真を返します。
パッケージのバージョンを見る
補足： 求めるパッケージ名自体はインストールされていないものの、他のパッケージから与えられていたり置き換えられていたりする場合は
nullを返します。 したがって少なくともライブラリのコードでは、satisfies()を使うことをお勧めします。 アプリケーションのコードではもう少し制御できるため、あまり重要ではありません。
// vendor/packageがインストールされている場合、正規化されたバージョン（例：1.2.3.0）が返ります。
// パッケージが提供されたり置き換えられたりしたものであればnullを返します。
// パッケージが全くインストールされていなければOutOfBoundsExceptionを投げます。
\Composer\InstalledVersions::getVersion('vendor/package');
// vendor/packageがインストールされていれば元のバージョン（例：v1.2.3）を返します。
// 提供されたり置き換えられたりしたものであればnullを返します。
// パッケージが全くインストールされていなければOutOfBoundsExceptionを投げます。
\Composer\InstalledVersions::getPrettyVersion('vendor/package');
// vendor/packageがインストールされていれば、パッケージのdistまたはsourceの参照（例：gitのコミットハッシュ）を返します。
// 提供されたり置き換えられたりしたものであればnullを返します。
// そのパッケージが全くインストールされていなければOutOfBoundsExceptionを投げます。
\Composer\InstalledVersions::getReference('vendor/package');
パッケージ自体のインストールされたバージョンを見る
パッケージ自体のバージョンを取得することにのみ関心がある場合、getVersion/getPrettyVersion/getReferenceで充分でしょう。 例えばacme/fooのソースで、現在実行中のacme/fooのバージョンがどれかを利用者に表示したい場合などです。
上の節の警告はこの場合には適用されません。 なぜならコードが走っている場合はパッケージは存在しており置き換えられてもいないからです。
とはいうものの、できる限りの安全性のためにnullの返り値まで心を配って制御することは良い考えです。
より複雑な用例については他の方法がいくつか利用できます。 クラス自体のソースやドキュメント部分を参照してください。
パッケージがインストールされているパスを見る
getInstallPathメソッドはパッケージがインストールされている絶対パスを取得します。
補足： パスは絶対的ではありますが、
../やシンボリックリンクは含まれることがあります。realpath()と等価なものであるという保証はないので、問題に挙がる状況ではrealpathを走らせるべきです。
// vendor/packageがインストールされていればパッケージのインストール場所への絶対パスを返します。
// 提供されていたり置き換えられていたり、あるいはパッケージがメタパッケージの場合はnullを返します。
// そのパッケージが全くインストールされていなければOutOfBoundsExceptionを投げます。
\Composer\InstalledVersions::getInstallPath('vendor/package');
Composer 2.1から使えます（つまり
composer-runtime-api ^2.1です）
与えられた種類でどのパッケージがインストールされているのかを見る
getInstalledPackagesByTypeメソッドはパッケージの種類（例：foo-plugin）を受け入れ、インストールされているその種類のパッケージを一覧にします。
その後、上記のメソッドを使用して、必要に応じて各パッケージに関する詳細情報を取得できます。
この方法により、プラグインをベンダーディレクトリに残すのではなく、特定のパスに配置するカスタムインストーラーの必要性が軽減されます。 それからInstalledVersionsを介して実行時に初期化するプラグインを見付け、必要に応じてgetInstallPathを介してそれらのパスを含めることができます。
\Composer\InstalledVersions::getInstalledPackagesByType('foo-plugin');
Composer 2.1から使えます（つまり
composer-runtime-api ^2.1です）
プラットフォームの検査
composer-runtime-api
2.0では新しいvendor/composer/platform_check.phpファイルが導入されました。
Composerの自動読み込み器を含めた際に、自動的に含まれます。
プラットフォーム要件（つまり、php及びphp拡張機能）が現在実行中のPHPプロセスで満たされていることを確認します。 要件が満たされていない場合、スクリプトは不足している要件に関する警告を出力し、コード104で終了します。
実稼働環境で予期せず失敗した際のPHP拡張機能の曖昧な警告が表示される空白ページを回避するには、デプロイやビルドの工程の一部としてcomposer check-platform-reqsを実行し、0以外のコードが返された場合に中止すると良いでしょう。
既定値はphp-onlyであり、PHPのバージョンのみを検査します。
何らかの理由でこの安全性の検査を使いたくなく、コードが実行されるときの実行時の失敗の惧れを許容する場合は、platform-check構成オプションをfalseに設定することで無効にできます。
検査にPHP拡張機能が存在することの検証を含めたい場合は、configオプションをtrueに設定します。
その後、ext-*の要件が検証されますが、効率上の理由から、Composerは拡張機能の存在のみをチェックし、その正確なバージョンは検査しません。
lib-*の要件は、プラットフォーム検査機能では全く対応されておらず、検査もされません。
バイナリの自動読み込みパス
composer-runtime-api
2.2では、Composerでインストールされたバイナリを実行するときに設定される$_composer_autoload_path大域変数が新しく導入されました。
詳細については、ベンダーバイナリドキュメントを参照してください。
バイナリプロキシによって設定されるので、Composerのvendor/autoload.phpではプロジェクトに使うことはできません。
このファイルはそれ自体を指すように戻ってしまうので、役に立たないのです。
バイナリパス (bin-dir)
composer-runtime-api 2.2.2では、新しい$_composer_bin_dir大域変数が導入されました。
Composerでインストールされたバイナリを使った際に設定されます。
これについての詳細はベンダーバイナリのドキュメントをお読みください。
バイナリプロキシによって設定されるため、Composerのvendor/autoload.phpによるプロジェクトでは利用できません。