基本的な使い方

インストール

Composerをインストールするために、composer.pharの実行ファイルをダウンロードする必要があります。

$ curl -sS https://getcomposer.org/installer | php

詳細はイントロダクションの章を見てください。

Composerが動作するかチェックするために、phpでPHARを実行してください。

$ php composer.phar

利用できるコマンドの一覧が表示されるでしょう。

注意: --checkオプションを使えばComposerをダウンロードせずに、チェックだけを行うこともできます。 より詳しい情報は--helpオプションを使ってみてください。

$ curl -sS https://getcomposer.org/installer | php -- --help

composer.json: プロジェクトのセットアップ

Composerをあなたのプロジェクトで利用するのに必要となるものはcomposer.jsonファイルだけです。 このファイルにはプロジェクトの依存情報が記述されます。そしてその他のメタデータも含まれるかもしれません。

JSONフォーマットは書くのがとても簡単です。 これはネストした構造を定義することができます。

requireキー

最初に（そして、しばしばただひとつの）あなたがcomposer.jsonで指定するものは、requireキーです。 あなたはComposerにプロジェクトが依存しているパッケージがどれであるかを、単に定義するだけです。

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

見たとおり、requireはパッケージ名 (例:monolog/monolog) と パッケージバージョン (例:1.0.*) で指定されたオブジェクトを扱います。

パッケージ名

パッケージ名はベンダー名とプロジェクト名から成ります。これらはしばしば同一になります。 - ベンダー名はネーミングが衝突するのを避けるためだけにあります。 異なった二人の人物がjsonという名前のライブラリ、igorw/jsonとseldaek/jsonを作成できます。

私たちはmonolog/monologを必要としていますね。ベンダー名はプロジェクト名と同じです。 ベンダー名はプロジェクトにとってユニークな名前であることが推奨されます。 また関連するプロジェクトを同じネームスペース配下に加えることもできます。 もしあなたがライブラリをメンテナンスしているのならば、これを小さいパートに分けることは本当に簡単でしょう。

パッケージバージョン

前述の例で、私たちはmonologのバージョン1.0.*を必要としていました。 これは1.0の開発ブランチの全てのバージョンのことです。 1.0.0、1.0.2、1.0.20全てに当てはまります。

バージョンの制約はいくつかの方法で指定できます。

名称	例	説明
特定のバージョン	1.0.2	パッケージの特定のバージョンを指定できます。
レンジ	>=1.0 >=1.0,<2.0 >=1.0,<1.1 | >=1.2	比較演算子で有効なバージョンの範囲を指定できます。 使用できる演算子は>, >=, <, <=, !=です。 カンマ区切りで論理積(logical AND)、パイプ|で論理和(logical OR)として扱われる範囲を複数指定できます。 ANDはORより優先されます。
ワイルドカード	1.0.*	ワイルドカード*でパターン指定をできます。1.0.* は>=1.0,<1.1と同じです。
チルダ演算子	~1.2	これはセマンティックバージョニングに従っているプロジェクトにおいてとても便利です。~1.2は>=1.2,<2.0と同じです。詳細は次のセクションを読んでください。

次の重要なリリース (チルダ演算子)

~1.2の例は~演算子の説明としてベストです。これは>=1.2,<2.0と同義です。 一方、~1.2.3は>=1.2.3,<1.3と同義です。 ごらんの通り、これはセマンティックバージョニングに準拠しているプロジェクトにおいてとても便利です。 最も一般的な使い方は、~1.2(2.0は含まず全てのアップロードを許可する)のように、 あなたが依存している最小のマイナーバージョンをマークすることでしょう。 理論上は、2.0までの動作について後方互換性の破壊がなくなるでしょう。 もう一つの使い方は、~を最小のバージョンに指定することです。 これは指定された末尾の数値の更新を許可します。

安定性

デフォルトでは安定版のリリースのみが考慮されます。依存物にRC、ベータ、アルファ版、または開発バージョンを扱いたい場合 安定性フラグを使うことができます。 依存物ごとにそれを設定する代わりに、全てのパッケージを変更するための最小の安定性設定を使うこともできます。

依存物をインストール

ローカルのプロジェクトに定義した依存物をフェッチするために、composer.pharのinstallコマンドを実行します。

$ php composer.phar install

これは指定したバージョン制約にマッチするmonolog/monologの最新バージョンを見つけて、vendorディレクトリ内にダウンロードします。 サードパーティのコードをvendorという名前のディレクトリ内におくことは慣習です。 monologの場合、vendor/monolog/monologに置かれます。

Tip: gitをプロジェクトで使っているのなら、多分.gitignoreにvendorを追加したいでしょう。 リポジトリにコードを追加したくないので。

installコマンドがするもう一つのことは、composer.lockファイルをプロジェクトルートに追加することです。

composer.lock - ロックファイル

依存物をインストールしたあとに、Composerはインストールしたパッケージの実際のバージョンのリストをcomposer.lockに書き込みます。 このファイルはプロジェクトをこれらの特定バージョンにロックします。

アプリケーションの composer.lockを(composer.jsonと一緒に)バージョンコントロールにコミットしてください。

これは重要なことです。なぜならinstallコマンドはロックファイルが存在するかチェックし、 あるならそこに指定されているバージョンをダウンロードするからです。 (composer.jsonの内容に関わらず)

これはプロジェクトをセットアップするのが誰であっても厳密に同じバージョンの依存物をダウンロードする、ということです。 CIサーバ、プロダクションマシン、チーム内の他のデベロッパー、全てで、誰でも同じ依存物を実行します。 これは、開発への潜在的なバグの影響を軽減します。 たとえあなたが一人で開発していたとしても、6ヶ月の間にプロジェクトを再インストールしたとき、 依存物がその後多くの新しいバージョンをリリースしていたとしても、 あなたはインストールされた依存物がちゃんと動くことを確信できます。

composer.lockファイルがない場合、Composerは依存物とバージョンをcomposer.jsonから読み、 ロックファイルを作成します。

これは、依存物に新しいバージョンがあった場合に自動的にはアップデートしないということです。 新しいバージョンにアップデートするためには、updateコマンドを使います。 これはマッチする最新のバージョン(composer.jsonファイルによります)をフェッチしロックファイルをその新しいバージョンで アップデートします。

$ php composer.phar update

一つの依存物をインストール、またはアップデートしたいだけなら、ホワイトリストが使えます。

$ php composer.phar update monolog/monolog [...]

注意: ライブラリの場合はロックファイルのコミットは不必要です。 ライブラリ - ロックファイルを参照してください。

Packagist

PackagistはメインのComposerリポジトリです。 Composerリポジトリは基本的なパッケージソースになります。 これはパッケージを取得元となる場所のことです。 Packagistは全ての人が利用できる中央リポジトリであることを目的としています。 この場所で利用できるパッケージは自動的にrequireできるということです。

packagistのWebサイト (packagist.org)ではパッケージを参照、検索できます。

Composerを使っているオープンソースプロジェクトはそのパッケージをpackagist上で公開するべきです。 Composerを使うために、ライブラリをpackagistに載せる必要ありません。 しかしそうすることで人生がかなりシンプルになります。

オートローディング

オートロード情報を指定するライブラリのためにComposerはvendor/autoload.phpファイルを生成します。 単にこのファイルをインクルードすれば、オートローディングを自由に手に入れることができます。

require 'vendor/autoload.php';

これはサードパーティコードの利用を本当に簡単にします。例：プロジェクトがmonologに依存している場合、 単にクラスをこのように始めればいいだけなのです。これでオートロードが行われます。

$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));

$log->addWarning('Foo');

composer.jsonにautoloadフィールドを追加すれば、自分のコードでさえオートローダに追加することができます。

{
    "autoload": {
        "psr-0": {"Acme\\": "src/"}
    }
}

ComposerはPSR-0オートローダをAcmeネームスペースに登録します。

ネームスペースからディレクトリへのマッピングを定義しています。 srcディレクトリはプロジェクトルートにあるとします。同じ階層にvendorもあります。 例えば、ファイル名がsrc/Acme/Foo.phpはAcme\Fooクラスを含みます。

autoloadフィールドを追加したあと、vendor/autoload.phpを再生成するためinstallを再実行しなければなりません。

オートロードファイルのインクルードはまた、autoloaderインスタンスを戻します。 なのでインクルード呼び出しの戻り値を変数に保持しておくことができます。 そして、ネームスペースを追加することができます。 これはテストスイート内で便利です。例えば、

$loader = require 'vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);

PSR-0オートローディングに加えて、クラスマップもまたサポートしています。 これはPSR-0に準拠していなくてもクラスをオートロードすることができます。 詳細はオートロードリファレンスを参照してください。

注意: Composerは自前のオートローダを提供しています. もしそれを使いたくない場合は 単にvendor/composer/autoload_namespaces.phpをインクルードすることができます。 これはネームスペースとディレクトリをマッピングしている連想配列を戻します。

← イントロダクション | ライブラリ →

誤字を見つけましたか？ 何か間違いがありますか？ forkして編集してください！