Composerの基本的な使用方法を紹介としてログ出力monolog/monologをインストールします。
Note:
以下ではComposerをWindowsインストーラによりインストールした環境を前提とします。原本ではcomposerをプロジェクトフォルダにインストールしてphp composer.phar {コマンド}で実行していますが、本編ではcomposer {コマンド}で実行することにします。
プロジェクトでComposerの使用を開始するために必要なのは composer.json ファイルだけです。このファイルにはプロジェクトの依存関係が記述されており、他のメタデータも含まれている場合があります。
composer.json で指定する最初のものは requireキー です。これは単にプロジェクトが依存するパッケージをComposerに伝えるだけです。
{ "require": { "monolog/monolog": "1.0.*" } }
このように、requireキーはパッケージ名（上例では、monolog/monolog）をバージョンの制約（上例では、1.0.*）にマップする情報を受け取ります。
Composerはこの情報を使用して正しいファイルセットを検索します。この時、repositoriesキーを使用して登録したパッケージリポジトリか、またはデフォルトのパッケージリポジトリである Packagist が使用されます。上記の例では、composer.jsonファイルに他のリポジトリが登録されていないため、monolog/monologパッケージが Packagist に登録されていると想定されています（Packagistについては以下を、他のについてはこちらを参照して下さい）。
パッケージ名は、ベンダー名とプロジェクト名で構成されます。多くの場合、これらは同一です（ベンダー名は、名前の衝突を防ぐためにのみ存在します）。例えば、2人の異なる人がjsonという同じ名前でライブラリを作成できるようにします（1人は igorw/json という名前で、もう1人は seldaek/json という名前で）。
パッケージの公開とパッケージの命名の詳細についてはこちらをご覧ください。（依存関係としてプラットフォームパッケージを指定することもできます。例えば、PHPやPHPエクステンションがこれに相当します。これにより、サーバーソフトウェアの特定のバージョンを要求できます。以下のプラットフォームパッケージを参照してください。）
上の例では、バージョン制約として 1.0.* でMonologパッケージをリクエストしています。これは、開発のブランチが 1.0 のバージョン、または 1.0以上 1.1未満 ( 1.0 ⇐ Version < 1.1 )のバージョンを意味します。
バージョン、バージョンの相互関係、およびバージョン制約に関する詳細な情報については、こちらをお読みください。
Composerは適切なファイルをどのようにダウンロードしますか？
composer.jsonで依存関係を指定すると、Composerは最初に要求したパッケージの名前を取得し、repositoriesキーを使用して登録したリポジトリで検索します。追加のリポジトリを登録していない場合、または指定したリポジトリでその名前のパッケージが見つからない場合、Packagistにフォールバックします（詳細は以下を参照）。
Composerは、Packagistまたは指定したリポジトリで適切なパッケージを見つけると、パッケージのVCS(バージョン管理システム)のバージョン管理機能（つまり、ブランチとタグ）を使用して、指定したバージョン制約に最適なものを見つけようとします。バージョンとパッケージの解決についてに記事は必ずお読みください。
Note:
パッケージを要求しようとした時にComposerがパッケージの安定性に関するエラーをスローした場合は、指定したバージョンがデフォルトの最小安定性要件を満たしていない可能性があります。デフォルトでは、VCSで有効なパッケージバージョンを検索する場合に安定したリリースのみが考慮されます。パッケージの開発版、α版、β版、またはRC版を必要とする場合、このような事態に遭遇する可能性があります。その時はこちらのページで、安定性フラグとminimum-stabilityキーの詳細をご覧ください。
プロジェクトに定義された依存関係をインストールするには、““install”“コマンドを実行します。
composer install
このコマンドを実行すると、次の2つのいずれが発生するでしょう。
以前にコマンドを実行したことがなく、且つ composer.lockファイルも存在しない場合、Composerは単純に ”“composer.json”” ファイルにリストされているすべての依存関係を解決し、それらのファイルの最新バージョンをプロジェクトの ““vendor”” ディレクトリにダウンロードします（““vendor”“ディレクトリは、プロジェクト内のすべてのサードパーティコードの為の習慣的な場所です）。
上記の例では、”“vendor/monolog/monolog/” に ”“Monolog”“ のソースファイルが作成されます。”“Monolog”“ に依存関係がリストされている場合、それらのソースファイルもまた ”“vendor/”“ の下のフォルダーに作成されます。
Tip:
プロジェクトでgitを使用している場合は、おそらく”“.gitignore”“ に”“vendor”“ディレクトリ内の追加する必要があります。その理由は、すべてのサードパーティコードをバージョン管理されたリポジトリに追加するをの本当は望まないからです。
Composerはインストールが完了すると、”“composer.lock”“ ファイルにダウンロードした全てのパッケージとそれらの正確なバージョンを書き込み、プロジェクトをそれらの特定のバージョンにロックします。”“composer.lock”“ ファイルをプロジェクトリポジトリにコミットして、プロジェクトで作業している全ての人が同じバージョンの依存関係にロックされるようにする必要があります（それについては以下で詳しく説明します）。
2番目のシナリオに進みます。”“composer install”“ を実行時に ”“composer.json”“ファイル と ”“composer.lock”“ファイル” とがすでに存在する場合は、あなたが以前に ““install”” コマンドを実行したか、または（これは良いことなのですが）プロジェクトの誰かが ““install”” コマンドを実行して ““composer.lock”” ファイルをプロジェクトにコミットしたことを意味します。
いずれにせよ、““composer.lock”” ファイルが存在するときのインストールでは、““composer.json”” にリストされたすべての依存関係が解決及びインストールされますが、Composerは““composer.lock”” にリストされた正確なバージョンを使用して、パッケージバージョンの一貫性を確かなものにします。
その結果として、““composer.json”“ファイルによって要求される全ての依存関係は満たされるものの、その依存関係は最新バージョンではない可能性があります。（なぜなら、”“composer.lock”“ファイルにリストされている依存関係の一部は、そのファイルの作成以降に新しいバージョンがリリースされた可能性があるからです）。これは仕様によるものであり、依存関係の予期しない変更によってプロジェクトが破損しないようにするためです。
composer.lock をVCS(バージョン管理システム)にコミットすることは重要です。それは、プロジェクトをセットアップする全ての人が、まったく同じバージョンの依存関係を使用するからです。CI(継続的インテグレーション)サーバー、実稼働マシン、チーム内の他の開発者、全てのもの、全ての人が同じ依存関係で実行します。これにより、一部の配置だけに関わるバグの可能性が軽減されます。
単独で開発した場合でも、プロジェクトを再インストールする6か月後に、依存関係がその後に多くの新しいバージョンをリリースしていた場合でさえ、先にインストールした依存関係がまだ機能していると確信できます。（update コマンドの使用については、以下を参照してください。）
前述のように、composer.lock ファイルは、依存関係の最新バージョンを自動的に取得することを防ぎます。最新バージョンに更新するには、updateコマンドを使用します。これにより、composer.jsonファイルに従って最新の一致するバージョンがフェッチされ、ロックファイルが新しいバージョンで更新されます。（これは composer.lock ファイルを削除して install を再度実行することと同じです。）
composer update
Note:
Composerは、composer.jsonに変更が加えられた後composer.lockが更新されていない場合、依存関係の解決に影響する可能性があるため、installコマンドの実行時に警告を表示します。
1つの依存関係のみをインストールまたは更新する場合は、それらをホワイトリストに登録できます。
composer update monolog/monolog [...]
Note:
ライブラリについては、ロックファイルをコミットする必要はありません。ライブラリ-ロックファイルも参照してください。
Packagistは、Composerのメインリポジトリです。Composerリポジトリは、基本的にはパッケージソース、つまりパッケージを取得できる場所です。Packagistは、誰もが使用する中心的なリポジトリを目指しています。これは、Composerがパッケージを探す場所をさらに指定することなく、そこで使用可能なパッケージを自動的に要求できることを意味しています。
Packagist のWebサイト( {packagist.org ）にアクセスすると、パッケージを参照と検索できます。
Compagerを使用しているオープンソースプロジェクトは、Packagist でパッケージを公開することをお勧めします。ライブラリは、Composerによって使用される Packagist 上に存在する必要はありませんが、そのことは、他の開発者による発見と採用をより迅速に行うことができます。
Composer has platform packages, which are virtual packages for things that are installed on the system but are not actually installable by Composer. This includes PHP itself, PHP extensions and some system libraries.
Composerにはプラットフォームパッケージ呼ばれるパッケージがあります。これは仮想的なパッケージのことで、システムにインストールされているものの、Composerによって実際にはインストールできないパッケージのことです。このプラットフォームパッケージには、PHP自体、PHP拡張機能、及び幾つかのシステムライブラリが含まれます。
phpは、ユーザーのPHPバージョンを表し、制約を適用できます（例えば、^7.1のような）。64ビット版のphpを要求するには、 php-64bit と requireします。hhvm は、HHVMランタイム（Facebookが開発したPHP実行環境）のバージョンを表し、制約を適用できます（例えば、^2.3）。ext-<name> を使用すると、PHP拡張機能（コア拡張機能を含む）を要求できます。ここではバージョニングが非常に矛盾する可能性があるため、多くの場合、制約を * に設定することをお勧めします。拡張パッケージ名の例は ext-gdです。lib-<name> を使用すると、PHPで使用されるライブラリのバージョンに制限を加えることができます。次のものが利用可能です：
curl , iconv , icu , libxml , openssl , pcre , uuid , xsl
composer show –platform を使用して、ローカルで利用可能なプラットフォームパッケージのリストを取得することができます。
オートロード情報が指定されたライブラリの場合、Composer は vendor/autoload.php ファイルを生成します。そして、このファイルを含めるだけで、追加の作業なしでライブラリが提供するクラスを使用することができます。
require __DIR__ . '/vendor/autoload.php'; $log = new Monolog\Logger('name'); $log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING)); $log->addWarning('Foo');
composer.json に autoloadフィールドを追加することで、オートローダーに独自のコードを追加することもできます。
{ "autoload": { "psr-4": {"Acme\\": "src/"} } }
この例では、Acme 名前空間に PSR-4 オートローダーを登録しています。
そして、ここでは名前空間からディレクトリへのマッピングを定義しています。src ディレクトリは、vendor ディレクトリと同じレベルのプロジェクトルートにあります。ファイル名の例を１つ挙げると、Acme\Fooクラスは src/Foo.php ディレクトリに含まれます。
autoloadフィールドを追加した後は、次のコマンドを実行して下さい。
composer dump-autoload
このコマンドは vendor/autoload.php ファイルを再生成します。 詳細については、dump-autoload セクションを参照してください。
vendor/autoload.php をインクルードするとautoloaderインスタンスも返されるので、インクルードの戻り値を変数に保存し、ネームスペースを追加できます。これは、例えばテストスイートでクラスをオートロードする場合に役立ちます。
$loader = require __DIR__ . '/vendor/autoload.php'; $loader->addPsr4('Acme\\Test\\', __DIR__);
Composerは、PSR-4の自動ロードに加えて、PSR-0、クラスマップ、およびファイルの自動ロードもサポートしています。 詳細については、autoloadリファレンスを参照してください。
オートローダーの最適化に関するドキュメントも参照してください。
Note:
Composerは独自のオートローダーを提供します。これを使用したくない場合は、vendor/composer/autoload_*.phpファイルをインクルードすることができます。このファイルは、連想配列を返し、あなた独自のオートローダーを設定することできます。