Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Composer

PHPのための依存関係管理

ComposerはPHPのプロジェクトの依存関係を宣言し、管理し、インストールする助けになります。

詳細情報とドキュメントについてはhttps://getcomposer.org/を参照してください。

Continuous Integration

インストールと使い方

公式の解説に従い、ダウンロード、インストールしてください。

使用方法についてはドキュメントを参照してください。

パッケージ

Packagist.orgに公開されているパッケージがあります。

私有パッケージのホスティングについては私有Packagistをご確認ください。

コミュニティ

告知についてはTwitterで@packagistまたは@seldaekをフォローしたり、#composerphpハッシュタグを確認したりしてください。

サポートについては、Stack OverflowでComposerに関係する良い質問がされてきました。 また、GitHubディスカッションも使えます。

本プロジェクトは貢献者の行動規範の元でリリースされている点にご留意ください。 本プロジェクトとコミュニティへ参加すると、これらの条項を遵守することに同意したこととなります。

要件

最新のComposer

最新版にはPHP 7.2.5以上が必要です。

Composer 2.2 LTS（長期期間対応）

PHPのバージョン5.3.2から8.1まではComposer (2.2.x)のLTS対応でまだ対応されています。 インストーラのself-updateコマンドを走らせると、手元のPHPに見合う適切なComposerのバージョンが自動的に選択されるでしょう。

バイナリの依存関係

  • 7z（ないし7zz）
  • unzip（7zが無い場合）
  • gzip
  • tar
  • unrar
  • xz
  • Git (git)
  • Mercurial (hg)
  • Fossil (fossil)
  • Perforce (p4)
  • Subversion (svn)

大事なことですが、これらのバイナリの依存関係の必要性は個々の用途によって様々です。 しかし殆どの利用者にとっては、Composerに必須な依存関係はたった2つです。 7z（または7zzやunzip）とgitです。

作者

本プロジェクトに参加している貢献者の一覧もご参照ください。

セキュリティ報告書

慎重を要する問題については全てsecurity@packagist.orgにお送りください。 ありがとうございます。

利用許諾

ComposerはMITライセンスの下で利用が許諾されます。 詳細はLICENSEをご参照ください。

謝辞

  • 本プロジェクトのSolverについて、openSUSEのLibzypp satsolverのPHP移植を開始しました。

本和訳にあたっての著作権表示を以下に示します。

Copyright (C) 2013--2015 kohkimakimoto.
Copyright (C) 2022--2024 gemmaro.

この翻訳はkohkimakimoto氏による翻訳を元に改変を加えています。 同氏の翻訳リポジトリはkohkimakimoto/getcomposer.org_doc_jpに、Webサイトは『Composer ドキュメント日本語訳』の「はじめに」にあります。 コミット9b7073bf08140994039b4c008650a0ce1e3173fb時点で翻訳されていた範囲は以下の通りです。

章名ファイル備考
イントロダクションdoc/00-intro.md
基本的な使い方doc/01-basic-usage.md
ライブラリdoc/02-libraries.md
コマンドラインインターフェースdoc/03-cli.md「install」節の「オプション」小節まで
composer.jsondoc/04-schema.md冒頭部分
コミュニティdoc/06-community.md

また、対応するComposer本体のコミットはa1e4ca4f9bacfd3dc08e0546bff2d30cb006ea27としました。

本翻訳は上記既訳を最新版に追従することを目的としています。 そのため既訳の修正に加えて新規に追加された原文への訳が含まれます。 本翻訳も原文にしたがい、MITライセンスの下に使用が許諾されます。

導入

ComposerはPHPの依存管理ツールです。 Composerはプロジェクトが依存するライブラリを宣言し管理（インストールやアップデート）できるようにするものです。

依存管理

ComposerはYumやAptの伝で言うとパッケージ管理ツールではありません。 「パッケージ」やライブラリを扱いはしますが、プロジェクト毎の管理であって、プロジェクトの内部のディレクトリ（例：vendor）にインストールするのです。 既定では決して大域的にインストールしません。 したがって、依存管理なわけです。 とはいえ便宜上globalコマンドを介して「大域的な」プロジェクトに対応してはいます。

このアイデアは新しいものではありません。 Composerはnodeのnpmやrubyのbundlerに強く影響を受けています。

想像してみてください。

  1. 大量のライブラリに依存したプロジェクトがある。
  2. 別のライブラリに依存するライブラリがある。

Composerでは次のことができます。

  1. 依存するライブラリを宣言できる。
  2. どのパッケージのどのバージョンをインストールする必要があるのかを調べて、インストールする（つまりプロジェクト内にパッケージをダウンロードします）。
  3. 1つのコマンドで全ての依存関係を更新できます。

依存関係の宣言についての詳細は基本的な使い方の章を参照してください。

システム要件

最新のComposerが動作するためにはPHP 7.2.5が必要です。 歴史的なPHPのバージョンで止まっている場合は長期サポート版 (2.2.x) がまだPHP 5.3.2以上に対応しています。 また、いくつかの細かいPHPの設定とコンパイルフラグも必要ですが、要件が合っていない箇所については、インストーラが警告を出すでしょう。

Composerが効率的に動作するには、幾つかの補助的なアプリケーションが必要です。 これらはパッケージの依存関係を扱う処理をより効率的にするものです。 ファイルを解凍するために、Composerは7z（或いは7zz）、gzip、tar、unrar、unzip、xzのようなツールに依っています。 バージョン管理システムについては、ComposerはFossil、Git、Mercurial、Perforce、Subversionと間断なく協調し、これにより円滑なアプリケーションの操作とライブラリのリポジトリの管理を確実にします。 Composerを使う前にこれらの依存関係が正しくシステムにインストールされていることをご確認ください。

Composerはマルチプラットフォームであり、Windows、Linux、macOSのそれぞれで同じように動作するよう努めています。

Linux / Unix / macOSへのインストール

実行形式のComposerをダウンロード

Composerには便利なインストーラがあり、コマンドラインから直接実行できます。 気兼ねなくこのファイルをダウンロードしたり、インストーラの内部のはたらきについてもっと知りたいと思ったらGitHubで確認したりしてください。 ソースは単なるPHPです。

平たく言うとComposerのインストールには2つの方法があります。 プロジェクトへローカルに入れる方法と、システム全域の実行ファイルとしてグローバルに入れる方法です。

ローカル

Composerをローカルにインストールするためには、プロジェクトのディレクトリでインストーラを走らせてください。 解説はダウンロードページを参照してください。

インストーラははいくつかのPHPの設定内容を確認して、composer.pharを作業ディレクトリにダウンロードします。 このファイルはComposerのバイナリです。 PHAR (PHP archive) はPHPのためのアーカイブ形式であり、コマンドラインから実行できますし、他の方法もあります

ここでComposerを走らせるにはphp composer.pharとしてください。

--install-dirオプションを使って特定のディレクトリに、更に--filenameオプションを使って命名（改名）しつつ、Composerをインストールできます。 ダウンロードページの説明に従ってインストーラを走らせるときは、以下の引数を加えてください。

php composer-setup.php --install-dir=bin --filename=composer

それから、php bin/composerとするとComposerが走ります。

大域的に使う

Composer PHARは好きな場所に置くことができます。 PATHの通った場所に置くことで大域的にアクセスできます。 Unix系のシステムでは実行形式にしてphpインタプリタを直接使わずに呼び出すこともできます。

ダウンロードページの説明に従ってインストーラを走らせた後は、以下を走らせてパスにあるディレクトリにcomposer.pharを移動させられます。

mv composer.phar /usr/local/bin/composer

利用者のためだけにインストールしてルート権限を避けたいようでしたら、代わりに~/.local/binを使うこともできます。 Linuxディストリビューションでは既定で使えることがあります。

注意: 上記がパーミッションによって失敗する場合、sudoで改めて実行する必要があるかもしれません。

補足： macOSのバージョンによって、既定では/usrディレクトリが存在しないことがあります。 エラー「/usr/local/bin/composer: No such file or directory」が出たら、予めmkdir -p /usr/local/binとしてディレクトリを手作りしなければなりません。

補足： パスを変えることに関してはWikipediaの記事を読んだりお好みの検索エンジンに掛けてみてください。

これでphp composer.pharの代わりにcomposerとすれば、Composerが走るようになりました。

Windowsへインストール

インストーラを使う

Composerをマシンに用意する最も簡単な方法です。

Composer-Setup.exeをダウンロードして実行してください。 最新バージョンのComposerがインストールされパスが設定されるため、どのディレクトリからもcomposerをコマンドラインから呼ぶことができます。

補足： 現在の端末を閉じてください。 新しい端末で使えるか試してみてください。 パスは端末が起動したときにのみ読み込まれるので、一旦閉じるのは大事です。

手動でインストール

composer.pharをダウンロードするため、PATHの通っているディレクトリに移動してダウンロードページの説明に従い、インストーラを走らせてください。

composer.batファイルをcomposer.pharと同じ場所に新規作成してください。

cmd.exeを使う場合：

C:\bin> echo @php "%~dp0composer.phar" %*>composer.bat

PowerShellを使う場合：

PS C:\bin> Set-Content composer.bat '@php "%~dp0composer.phar" %*'

まだPATH環境変数にディレクトリがなければ追加してください。 PATH変数を変えることに関してはこの記事を参照したりお好みの検索エンジンに掛けてみたりしてください。

現在の端末を閉じてください。 新しい端末で使えるか試してください。

C:\Users\username>composer -V

Composer version 2.4.0 2022-08-16 16:10:48

Dockerイメージ

Composerはいくつかの場所でDockerコンテナとして公開されています。 composer/dockerのREADMEで一覧を参照してください。

使用例：

docker pull composer/composer
docker run --rm -it -v "$(pwd):/app" composer/composer install

既存のDockerfileにComposerを加えるには、単に既にビルドされた小さいサイズのイメージからバイナリファイルを複製できます。

# 最新リリース
COPY --from=composer/composer:latest-bin /composer /usr/bin/composer

# 特定のリリース
COPY --from=composer/composer:2-bin /composer /usr/bin/composer

さらなる使い方の情報についてはイメージの説明をお読みください。

補足： Docker固有の問題はcomposer/dockerリポジトリに報告されると良いでしょう。

補足： 上のイメージ名ではcomposer/composerの代わりにcomposerを使うこともできます。 名前が短かく、Dockerの公式イメージですが、直接私達が公開したものではないので新しいリリースが数日送れで来ることが普通です。 重要：短い別名が付けられたイメージにはバイナリのみの同じものがないため、COPY --fromの方法についてはcomposer/composerのほうを使う方が良いです。

Composerを使う

これでComposerをインストールしたので使う準備ができました。 簡単な実演があるので次の章に向かいましょう。

基本的な使い方 →

基本的な使い方

導入

基礎的な使い方の導入として、ここではログライブラリであるmonolog/monologをインストールします。 まだComposerをインストールしていなければ、はじめに章を参照してください。

補足： 簡潔のために、この導入ではComposerのローカルインストールを実施した前提で進めます。

composer.json: プロジェクトの立ち上げ

プロジェクトでComposerを使い始めるにあたって必要なのはcomposer.jsonファイルだけです。 このファイルにはプロジェクトの依存関係が記述され、他のメタデータも含まれることがあります。 大抵プロジェクトやVCSリポジトリの最上位ディレクトリにあります。 技術的にはComposerをどこで実行することもできますが、パッケージをPackagist.orgに公開したいならば、VCSリポジトリの一番上の階層にファイルがなければなりません。

requireキー

最初にcomposer.jsonで指定するものは、requireキーです。 Composerにプロジェクトが依存しているパッケージがどれであるかを伝えるものです。

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

見ての通り、requireはパッケージ名（例：monolog/monolog）と パッケージバージョン（例：1.0.*）を対応付けるオブジェクトを取ります。

Composerはこの情報を使って、repositoriesキーからパッケージ「リポジトリ」や、既定のパッケージレジストリであるPackagist.orgにある正しいファイル一式を探します。 上の例ではこれといったリポジトリはcomposer.jsonファイルに登録されていないので、monolog/monologパッケージはPackagist.orgに登録されているものと推定されます（詳細はPackagistについてとリポジトリについてを参照）。

パッケージ名

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

詳細はパッケージの公開とパッケージの命名を読んでください（なお「プラットフォームパッケージ」を依存関係として指定することも可能で、サーバーのソフトウェアの特定のバージョンを要求できます。 プラットフォームパッケージで後述します）。

パッケージバージョン制約

先の例ではバージョン制約2.0.*のMonologパッケージを要求しています。 これが意味するものは2.0の開発ブランチの任意のバージョン、言い換えると2.0以上で2.1より小さい（>=2.0 <2.1）任意のバージョンのことを指します。

バージョンとバージョン間の関連、バージョン制約についてのより詳しい情報はバージョンを読んでください。

どうやってComposerは正しいファイルをダウンロードしているのか。 composer.jsonに依存関係を指定したとき、Composerはまず、repositoriesキーを使って登録された全てのリポジトリを対象に要求されたパッケージの名前を検索します。 もし1つも追加でリポジトリを登録していなかったり、指定したリポジトリにその名前のパッケージがなかったときは、Packagist.org（後述）に落ち着きます。

ComposerがPackagist.orgないし指定したリポジトリで正しいパッケージがあったときは、パッケージのVCSのバージョン機能（つまりブランチとタグ）を使って、指定したバージョン制約に最も合致するものを見付け出そうとします。 必ずバージョンについての記事でバージョンとパッケージについて読んでください。

補足： もしパッケージを要求したもののComposerがパッケージの安定性の理由で例外を投げた場合は、指定したバージョンが既定の最小の安定要件に見合わない可能性があります。 VCSで妥当なパッケージバージョンを探す際、既定では安定リリースのみが考慮されます。

パッケージの開発版、アルファ版、ベータ版、リリース候補のバージョンを要求しようとしたときに、この例外に遭遇するかもしれません。 安定性フラグとminimum-stabilityキーについての詳細はスキーマのページをお読みください。

依存物をインストール

定義された依存関係をプロジェクトに初めてインストールするときは、updateコマンドを走らせると良いです。

php composer.phar update

こうするとComposerは2つのことをします。

  • composer.jsonファイルに挙げられている全ての依存関係を解決して、全てのアッケージとその厳密なバージョンをcomposer.lockファイルに書き込みます。 このファイルによりプロジェクトが特定のバージョンに固定されます。 composer.lockファイルはプロジェクトのリポジトリにコミットすべきです。 そうすればプロジェクトに参画する全員にとって、同じバージョンの依存関係に固定されたものになります（詳細は後述）。 これがupdateコマンドの主な役割です。
  • それから暗黙裡にinstallコマンドが走ります。 これにより依存関係のファイルがプロジェクトのvendorディレクトリにダウンロードされます（vendorディレクトリはプロジェクトの全てのサードパーティコード用の定番の場所です）。 上の例では最終的にMonologのソースファイルがvendor/monolog/monologにあることになります。 Monologにはpsr/logへの依存関係があるため、そのパッケージのファイルもまたvendor/の中にあります。

コツ： gitをプロジェクトで使っているのなら、多分.gitignoreにvendorを追加したいでしょう。 実際のところ、バージョン管理されたリポジトリにサードパーティ製のコード全てを追加したくはないので。

composer.lockファイルをバージョン管理にコミットすること

このファイルをバージョン管理にコミットすることは大事です。 なぜならこうすることでプロジェクトの準備をする誰もが、自分が使っているものと全く同じバージョンの依存関係を使えるようになるからです。 CIサーバ、実運用マシン、チーム内の他の開発者、万物万人が同じ依存関係で実行するのです。 これにより特定のデプロイでのみ影響する潜在的なバグが低減されます。 たとえ一人で開発していて、6箇月経ってからプロジェクトを再インストールしたとしても、そして依存関係が多くの新しいバージョンをリリースされていたとしても、インストールされた依存関係がちゃんと動くことは疑いありません（updateコマンドの使用については以下の補足を参照してください）。

補足： ライブラリの場合、固定ファイルのコミットは不必要です。 ライブラリ - 固定ファイルも参照してください。

composer.lockからインストールする

既にcomposer.lockファイルがプロジェクトフォルダにあるなら、それは前に自分でupdateコマンドを走らせたか、プロジェクトの誰かがupdateコマンドを走らせてcomposer.lockファイルをプロジェクトにコミットしたからかのどちらかです（いいことです）。

何れにせよ、composer.lockファイルが存在しているときにinstallを走らせるとcomposer.jsonに挙がっている全ての依存関係を解決してインストールします。 ただしその際はプロジェクトの作業をしている人全員にとってパッケージのバージョンが必ず一貫したものになるように、Composerはcomposer.lockに挙げられた厳密なバージョンを使用します。 結果としてcomposer.jsonファイルで要求された全ての依存関係が取得されるのですが、必ずしも利用できるごく最新のバージョンとはなっていないかもしれません（ファイルが作成された後に、composer.lockファイルで挙げられた依存関係のより新しいバージョンがリリースされる可能性があります）。 これは設計上意図されたものであり、依存関係での予期しない変更による不具合がプロジェクトで絶対に発生しないようになっています。

そのためVCSリポジトリから新しい変更を取得した後は、Composerのinstallを走らせて、vendorディレクトリがcomposer.lockファイルと同期していることを確かめることをお勧めします。

php composer.phar install

Composerは既定で再生成可能な構築を有効にします。 つまり同じコマンドを複数回走らせると、自動読み込み器のファイルを含め、（タイムスタンプ以外）同値なファイルを含むvendor/ディレクトリを生成するのです。 厳密な検証過程を要求する環境や、PHPアプリケーションを安全で予測可能なやり方でパッケージ化することを目指すLinuxディストリビューションにおいては、特に有益です。

最新版に依存関係を更新する

前述したように、composer.lockファイルは自動的に依存関係の最新版が取得されるのを防ぎます。 最新のバージョンに更新するにはupdateコマンドを使います。 こうすると（composer.jsonファイルに沿うように）照合する最新バージョンを取得して新しいバージョンで固定ファイルを更新します。

php composer.phar update

補足： composer.jsonに依存関係解決に影響し得る変更が加えられた後にcomposer.lockが更新されていなければ、installコマンドを実行するときに、Composerが警告を表示します。

1つの依存関係をインストール、更新、削除したいだけなら、引数として明示的に列挙できます。

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

Packagist

Packagistは主眼のComposerリポジトリです。 Composerリポジトリは基本的にはパッケージの源です。 つまりパッケージを取ってくることができる場所のことです。 Packagistは全ての人が利用できる中央リポジトリであることを目指しています。 要はここで利用できるいかなるパッケージも自動的にrequireできるということです。 Composerがパッケージを探す場所を追加で指定しなくて良いのです。

packagistのWebサイトでは、パッケージを閲覧したり検索したりできます。

Composerを使っているオープンソースプロジェクトはパッケージをPackagist上で公開するべきです。 Composerを使う上で、ライブラリをPackagistに載せる必要はありません。 しかし公開することで、他の開発者がより素早くパッケージを発見して取り入れられるようになります。

プラットフォームパッケージ

Composerにはプラットフォームパッケージがあります。 システムにインストールされる仮想的なパッケージで、実際にはComposerではインストールされないものを指します。 PHP自身やPHP拡張、システムライブライリが含まれます。

  • phpは利用者のPHPバージョンを表しており、^7.1のような制約を適用できます。 PHPの64bitバージョンを要求するには、php-64bitパッケージを指定できます。

  • hhvmはHHVMランタイムのバージョンを表しており、^2.3のように制約を適用できます。

  • ext-<name>とすることでPHPの拡張を要件にできます（中核拡張を含みます）。 バージョニングはかなり一貫性がないことがあるので、大体の場合は制約に*を設定するのと良いです。 拡張パッケージ名の例はext-gdです。

  • lib-<name>はPHPで使われるライブラリのバージョンを制約します。 次のものが利用できます：curl, iconv, icu, libxml, openssl, pcre, uuid, xsl。

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->warning('Foo');

composer.jsonにautoloadフィールドを追加すれば、自分のコードについても自動読み込み器に追加できます。

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

ここではComposerがPSR-4自動読み込み器をAcme名前空間に登録しています。

名前空間からディレクトリへの対応付けが定義されます。 srcディレクトリはプロジェクトの根幹にあり、同じ階層にvendorもあるとしましょう。 ファイル名の例としてはAcme\Fooクラスを含むsrc/Foo.phpがあります。

autoloadフィールドを追加した後は、このコマンドを再び走らせなくてはなりません。

php composer.phar dump-autoload

このコマンドはvendor/autoload.phpファイルを再生成します。 詳細はdump-autoload節を参照してください。

自動読み込みファイルを含めるとautoloaderインスタンスを返します。 そのためインクルード呼び出しの返り値を変数に保持し、更に名前空間を追加できます。 テストスイート内での自動読み込みクラスに便利です。 例えば以下です。

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

PSR-4自動読み込みに加えて、ComposerはPSR-0、クラスマップ、ファイル自動読み込みにも対応しています。 詳細はautoloadリファレンスを参照してください。

autoloaderの最適化についてのドキュメントも参照してください。

注意： Composerは自前の自動読み込み器を提供しています。 もしそれを使いたくない場合は、単にvendor/composer/autoload_*.phpファイルを含められます。 自前の自動読み込み器を設定できる連想配列を返します。

← 導入 | ライブラリ →

ライブラリ

この章ではライブラリをComposerでインストールできるようにする方法を学びます。

全てのプロジェクトはパッケージである

composer.jsonをディレクトリに配置した時点で、そのディレクトリはパッケージとなります。 requireをプロジェクトに追加すると、他のパッケージに依存したパッケージを作っていることになります。 プロジェクトとライブラリの唯一の違いは、プロジェクトは名前のないパッケージだということです。

インストール可能なパッケージを作成するためには命名する必要があります。 composer.jsonにnameプロパティを追加してください。

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

この例では、プロジェクト名はacme/hello-worldです。 acmeはベンダー名です。 ベンダー名を与えることは必須です。

注意： もしベンダー名に何をつけていいか分からない場合は、大抵は自分のGitHubの利用者名をつけるといいでしょう。 パッケージ名は全て小文字でなければならず、単語の区切りはダッシュにするのが慣習です。

ライブラリのバージョン

まず間違いなくgit, svn, hg, fossilといった何らかの類のバージョン管理システムを使ってライブラリを管理することでしょう。 こうした場合、ComposerはVCSからバージョンを推定するのでcomposer.jsonファイルではバージョンを指定すべきではありません（ComposerがVCSのブランチとタグを使ってバージョン制約を解決する方法について学ぶためにはバージョンについての記事を参照してください）。

パッケージの管理を手作業でしている（つまりVCS無しの）場合、composer.jsonファイルにversion値を加えて、バージョンを明示的に指定する必要があるでしょう。

{
    "version": "1.0.0"
}

補足： VCSに埋め込まれているバージョンを加えた場合、バージョンはタグ名と干渉することでしょう。 そうするとComposerはバージョン値を決定できなくなります。

VCSのバージョン管理

ComposerはVCSのブランチとタグの機能を使ってrequireフィールドで指定したバージョン制約を特定のファイルの集まりに至るまで解決します。 利用できる妥当なバージョンを決定する際、Composerは全てのタグとブランチを見て、それらの名前を内部的なオプションの一覧に翻訳し、それから与えられたバージョン制約に対して照合します。

Composerがタグとブランチを扱う方法とパッケージのバージョン制約を解決する方法についての詳細は、バージョンの記事をお読みください。

固定ファイル

お望みならライブラリにcomposer.lockファイルをコミットできます。 チームが常に同じ依存バージョンでテストする際の助けになります。 しかし、この固定ファイルはこれに依存している他のプロジェクトにいかなる影響も齎しません。 主眼のプロジェクトのみに影響します。

もし固定ファイルをコミットしたくなくて、且つgitを使っている場合は、.gitignoreに追加してください。

VCSに公開する

composer.jsonファイルを含むVCSリポジトリ（バージョン管理システム、例えばgit）があれば、ライブラリは既にcomposerでインストール可能です。 この例ではGitHubでacme/hello-worldライブラリをgithub.com/username/hello-worldとして公開するとしましょう。

それではacme/hello-worldパッケージのインストールを試すために、ローカルに新しいプロジェクトを作成しましょう。 私たちはそれをacme/blogと呼ぶことにします。 このブログはacme/hello-worldに依存し、更にmonolog/monologに依存するとします。 以下のcomposer.jsonを含む新しいblogディレクトリを作成することで達成されます。

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

名前はこの場合必須ではありません。 このブログをライブラリとして公開することはないからです。 ここではどのcomposer.jsonが説明されているのかを明確にするために加えられています。

このブログアプリに依存物hello-worldの所在を知らせる必要があります。 これにはパッケージのリポジトリ指定をこのブログのcomposer.jsonに追加します。

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

パッケージリポジトリの挙動や他にどのようなタイプが利用できるかについての詳細は、リポジトリを参照してください。

これで全てです。 Composerのinstallコマンドを実行すれば依存関係をインストールできます！

まとめ： composer.jsonを含むあらゆるgit/svn/hg/fossilリポジトリは、requireフィールドでパッケージリポジトリを指定して依存関係を宣言することで、プロジェクトに追加できます。

Packagistに公開する

よろしい、今やパッケージを公開できるようになりました。 しかし、毎回VCSリポジトリを指定するのは厄介なことです。 全ての利用者にそんなことはさせたくないでしょう。

monolog/monologのためのパッケージリポジトリを指定しなかったこととにお気付きかもしれません。 どのような仕組みなのでしょうか？ 答えはPackagistです。

PackagistはComposerの主眼のパッケージリポジトリで、 既定で有効になっています。 Packagistで公開されている全てのものは自動的にComposerで利用可能です。 monologはPackagistにあるので、追加のリポジトリ指定なくして依存できるのです。

hello-worldを世界に共有したければ、同様にPackagistに公開するのが良いでしょう。

Packagistを開いて"Submit"ボタンを押します。 まだサインアップしていなかったらその旨の表示がされます。 それからVCSリポジトリのURLを送信できます。 送信した時点でPackagistはクローリングを始めます。 完了すると、パッケージは誰でも使えるようになります！

軽量配布パッケージ

有用でない情報は普通、配布パッケージに含めない方が良いでしょう。 これには.githubディレクトリ、嵩張る例、テストデータなどがあります。

.gitattributesファイルは.gitignoreのようなgit固有のファイルです。 またライブラリの根幹ディレクトリにあります。 これが存在してgitで追跡されているとき、局所的な構成と大域的な構成（それぞれ.git/configと~/.gitconfig）がオーバーライドされます。

zipの配布パッケージが肥大化させる望ましくないファイルが入らないようにするには、.gitattributesを使ってください。

// .gitattributes
/demo export-ignore
phpunit.xml.dist export-ignore
/.github/ export-ignore

生成されたzipファイルを手作業で調べて確認するには、次のようにします。

git archive branchName --format zip -o file.zip

補足： ファイルはgitで追跡されたままであり、zipの配布物に含まれていないだけです。 これはdist（タグ付けされたリリース）でインストールしたパッケージでのみ機能します。 配布元はGitHub、GitLab、BitBucketがあります。

← 基本的な使い方 | コマンドラインインターフェース →

コマンドラインインターフェース / コマンド

既にいろいろなことをするために、コマンドラインインターフェースの使い方は学びました。 この章は全ての利用可能なコマンドを説明します。

コマンドラインからヘルプを得るためには、composerまたはcomposer listを実行して全てのコマンドの完全な一覧を見ることができます。 更に--helpをそれらのコマンドと組み合わせれば、より多くの情報を得られます。

Composerはsymfony/consoleを使っているため、曖昧でなければ短い名前でコマンドを呼び出せます。

php composer.phar dump

上ではcomposer dump-autoloadを呼び出します。

Bashの補完

Bashの補完をインストールするには、composer completion bash > completion.bashと走らせられます。 現在のディレクトリにcompletion.bashファイルを作ります。

それからsource completion.bashを実行すれば現在の端末のセッションで有効になります。

completion.bashを/etc/bash_completion.d/composerに移動しつつ改名すれば、新しい端末で自動的に読み込まれるようにできます。

大域オプション

以下のオプションは全てのコマンドで利用できます。

  • --verbose (-v): メッセージの冗長さを増やす。
  • --help (-h): ヘルプ情報を表示する。
  • --quiet (-q): メッセージを一切出力しない。
  • --no-interaction (-n): 対話的な質問の問い合わせを一切行わない。
  • --no-plugins: プラグインを無効にする。
  • --no-scripts: composer.jsonで定義されているスクリプトの実行を飛ばす。
  • --no-cache: キャッシュディレクトリの使用を無効にする。 COMPOSER_CACHE_DIR環境変数を/dev/null（WindowsではNUL）に設定することと同じです。
  • --working-dir (-d): 指定すると、与えられたディレクトリを作業ディレクトリに使う。
  • --profile: 時間とメモリ使用量の情報を表示する。
  • --ansi: ANSI出力を強制する。
  • --no-ansi: ANSI出力を行わない。
  • --version (-V): 本アプリケーションのバージョンを表示する。

プロセスの終了コード

  • 0: OK
  • 1: 一般的ないし不明な失敗コード
  • 2: 依存解決の失敗コード

init

ライブラリの章でcomposer.jsonを手作りする方法を見ました。 こうしたことをするのにinitコマンドというのもあります。

このコマンドを実行すると、賢明な既定値を使いながら、対話的な問答を経てフィールドが埋められていきます。

php composer.phar init

オプション

  • --name: パッケージの名前。
  • --description: パッケージの説明。
  • --author: パッケージの作者名。
  • --type: パッケージの種類。
  • --homepage: パッケージのホームページ。
  • --require: バージョン制約付きの必要なパッケージ。書式はfoo/bar:1.0.0のようになります。
  • --require-dev: 開発のための要件です。--requireを参照。
  • --stability (-s): minimum-stabilityフィールド用の値。
  • --license (-l): パッケージの利用許諾。
  • --repository: 1つ（かそれ以上）の個別のリポジトリを与えます。 これらのリポジトリは生成されるcomposer.jsonに収められ、要件の一覧を提案する際の自動補完に使われます。 全てのリポジトリはcomposerリポジトリを指すHTTPのURLないしrepositoriesキーが受け付けるものと同様のJSON文字列の何れかを取ります。
  • --autoload (-a): composer.jsonへのPSR-4自動読み込みの対応付けを加えます。 自動的にパッケージの名前空間を与えられたディレクトリに対応付けます（src/のような相対パスを想定しています）。 PSR-4自動読み込みも参照してください。

install / i

installコマンドは現在のディレクトリからcomposer.jsonファイルを読み込み、依存物を解決し、vendor配下にインストールします。

php composer.phar install

現在のディレクトリにcomposer.lockファイルが存在する場合は、依存物を解決する代わりに、そこから厳密なバージョンを使います。 ライブラリを使う全ての利用者が同じバージョンの依存物を持つことを保証します。

composer.lockファイルがない場合、composerは依存物を解決した後で作成します。

オプション

  • --prefer-install: パッケージをダウンロードする方法はsourceとdistの2つあります。 Composerはdistを既定で使います。 --prefer-install=source（または--prefer-source）を渡すと、Composerは、もしあればsourceからインストールします。 プロジェクトへのバグ修正をして、依存関係のローカルgitクローンを直接取得したい場合に便利です。 Composerがパッケージの開発版用のsourceを自動的に使う、以前の挙動にしたければ、--prefer-install=autoを使ってください。 config.preferred-installも参照してください。 このフラグを渡すと、設定値より優先されます。
  • --dry-run: 実際にはパッケージをインストールすることなくインストールの過程を進めたいときは--dry-runを使うことができます。 インストールを模擬して何が起こるのかを示します。
  • --download-only: ダウンロードするのみで、パッケージをインストールしません。
  • --dev: require-devに挙げられたパッケージをインストールします（既定の挙動です）。
  • --no-dev: require-devに挙げられたパッケージのインストールを飛ばします。 自動読み込み器の生成でautoload-dev規則を読み飛ばします。 COMPOSER_NO_DEVも参照してください。
  • --no-autoloader: 自動読み込み器の生成を飛ばします。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --audit: インストールが完了した後に監査を走らせます。
  • --audit-format: 監査の出力形式です。 "table"、"plain"、"json"、または"summary"（既定）のどれかでなければなりません。
  • --optimize-autoloader (-o): PSR-0の自動読み込みをクラス対応表に変換して自動読み込みを高速にします。 実運用では特にお勧めしますが、走らせるのに少し時間が掛かることがあるので、現在は既定ではされません。
  • --classmap-authoritative (-a): クラス対応表からクラスのみを自動読み込みします。 暗黙裡に--optimize-autoloaderを有効にします。
  • --apcu-autoloader: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-autoloader-prefix: APCu自動読み込み器のキャッシュ用に独自の接頭辞を使います。 暗黙裡に--apcu-autoloaderを有効にします。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 ワイルドカードを使って複数の要件を無視できます。 +を後ろに付けることで要件の上限値だけを無視できます。 例えばパッケージがphp: ^7を要求しているとき、オプション--ignore-platform-req=php+はPHP8でのインストールを許しますが、PHP 5.6でのインストールについては失敗します。

update / u / upgrade

依存関係の最新版を取得してcomposer.lockファイルを更新する上ではupdateコマンドを使うと良いでしょう。 このコマンドにはupgradeの別名が付けられていますが、apt-getや類するパッケージ管理を連想したときにupgradeがすることと同じだからです。

php composer.phar update

こうするとプロジェクトの全ての依存関係を解決し、厳密なバージョンをcomposer.lockに書き込みます。

全てではなく、2、3のパッケージのみを更新したい場合は、以下のように列挙できます。

php composer.phar update vendor/package vendor/package2

ワイルドカードを使って複数のパッケージを一挙に更新することもできます。

php composer.phar update "vendor/*"

composer.jsonを変えることなくパッケージを指定のバージョンに巻き戻したいときは、--withを使うことができます。 このオプションには自分で選んだバージョン制約を与えます。

php composer.phar update --with vendor/package:2.0.1

なお上記では全てのパッケージが更新されます。 --withを使って自分で選んだ制約を与えたパッケージのみを更新するには、--withを省き、代わりに部分的な更新構文を持つ制約を使ってください。

php composer.phar update vendor/package:2.0.1 vendor/package2:3.0.*

補足： composer.jsonでも要求されているパッケージについては、自分で選んだ制約は既存の制約の部分集合でなければなりません。 composer.jsonでの制約は適用されたままであり、これらの一時的な制約の更新では変更されません。

オプション

  • --prefer-install: パッケージをダウンロードする方法はsourceとdistの2つあります。 Composerはdistを既定で使います。 --prefer-install=source（または--prefer-source）を渡すと、Composerは、もしあればsourceからインストールします。 プロジェクトへのバグ修正をして、依存関係のローカルgitクローンを直接取得したい場合に便利です。 Composerがパッケージの開発版用のsourceを自動的に使う、以前の挙動にしたければ、--prefer-install=autoを使ってください。 config.preferred-installも参照してください。 このフラグを渡すと、設定値より優先されます。
  • --dry-run: 実際には何もせず、コマンドを模擬します。
  • --dev: require-devに挙げられたパッケージをインストールします（既定の挙動です）。
  • --no-dev: require-devに挙げられたパッケージのインストールを飛ばします。 自動読み込み器の生成でautoload-dev規則を読み飛ばします。 COMPOSER_NO_DEVも参照してください。
  • --no-install: composer.lockを更新した後のインストール過程を走らせません。
  • --no-audit: composer.lockを更新した後の監査過程を走らせません。COMPOSER_NO_AUDITも参照してください。
  • --audit-format: 監査の出力形式です。 "table"、"plain"、"json"、または"summary"（既定）のどれかでなければなりません。
  • --lock: パッケージのバージョンを更新せず、固定ファイルが期限切れであることについての警告を抑えるために固定ファイルを上書きします。 ミラーやURLといったパッケージのメタデータが変更されていれば更新します。
  • --with: 一時的に追加するバージョン制約です。例えばfoo/bar:1.0.0やfoo/bar=1.0.0です。
  • --no-autoloader: 自動読み込み器の生成を飛ばします。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --with-dependencies (-w): 引数リスト中のパッケージの依存関係も更新します。 ただし根幹要件は除きます。 COMPOSER_WITH_DEPENDENCIES=1 環境変数で設定することもできます。
  • --with-all-dependencies (-W): 引数リスト中のパッケージの依存関係も更新します。 根幹要件を含みます。 COMPOSER_WITH_ALL_DEPENDENCIES=1 環境変数でも設定できます。
  • --optimize-autoloader (-o): PSR-0自動読み込みをクラスマップに変換して、より高速な自動読み込み器を取得します。 特に実運用で推奨されますが、走らせるのに少し時間が掛かるため、現時点では既定では有効になっていません。
  • --classmap-authoritative (-a): クラス対応表からクラスのみを自動読み込みします。 暗黙裡に--optimize-autoloaderを有効にします。
  • --apcu-autoloader: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-autoloader-prefix: APCu自動読み込み器のキャッシュ用に独自の接頭辞を使います。 暗黙裡に--apcu-autoloaderを有効にします。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 ワイルドカードを使って複数の要件を無視できます。 +を後ろに付けることで要件の上限値だけを無視できます。 例えばパッケージがphp: ^7を要求しているとき、オプション--ignore-platform-req=php+はPHP8でのインストールを許しますが、PHP 5.6でのインストールについては失敗します。
  • --prefer-stable: 依存関係の安定板を選ぶようにします。COMPOSER_PREFER_STABLE=1環境変数を介しても設定できます。
  • --prefer-lowest: 依存関係の最も低いバージョンを選ぶようにします。最小バージョン要件を試す際に便利で、一般的には--prefer-stableと共に使われます。COMPOSER_PREFER_LOWERST=1環境変数を介しても設定できます。
  • --minimal-changes (-m): 依存関係に関して絶対に必須の変更のみ行います。 パッケージが現在固定されているバージョンに留めておけないときは更新されます。 部分更新については、許可一覧にあるパッケージは常に完全に更新されます。 COMPOSER_MINIMAL_CHANGES=1環境変数でも設定できます。
  • --patch-only: 現在インストールされている依存関係について、パッチバージョンの更新のみ許可します。
  • --interactive: 自動補完付きの対話的なインターフェースで、更新するパッケージを選択します。
  • --root-reqs: 更新を一次依存関係に制限します。
  • --bump-after-update: 更新後にbumpを走らせます。 devやno-devを設定すると、それぞれの依存関係のみのバージョンを上げます。

引数として単語mirrors、lock、nothingからどれか1つを指定すると、オプション--lockを指定することと同じ効果があります。 例えばcomposer update mirrorsはcomposer update --lockと全く同じです。

require / r

requireコマンドはcomposer.jsonファイルに現在のディレクトリから新しいパッケージを追加します。1つもファイルが存在しなければ必要に応じて作られます。

パッケージを指定しない場合、Composerはパッケージを探すためにプロンプトを出し、要件にするものに照合する一覧を提供します。

php composer.phar require

要件を加えたり変えたりした後に、変更された要件がインストールされたり更新されたりします。

対話的に要件を選びたくなければコマンドに渡すこともできます。

php composer.phar require "vendor/package:2.*" vendor/package2:dev-master

バージョン制約を指定しなければ、composerは利用できるパッケージのバージョンに基づいて相応しいものを選びます。

php composer.phar require vendor/package vendor/package2

すぐには新しい依存関係をインストールしたくない場合は--no-update付きで呼べます。

オプション

  • --dev: パッケージをrequire-devに追加します。
  • --dry-run: 実際には何もせず、コマンドを模擬します。
  • --prefer-install: パッケージをダウンロードする方法はsourceとdistの2つあります。 Composerはdistを既定で使います。 --prefer-install=source（または--prefer-source）を渡すと、Composerは、もしあればsourceからインストールします。 プロジェクトへのバグ修正をして、依存関係のローカルgitクローンを直接取得したい場合に便利です。 Composerがパッケージの開発版用のsourceを自動的に使う、以前の挙動にしたければ、--prefer-install=autoを使ってください。 config.preferred-installも参照してください。 このフラグを渡すと、設定値より優先されます。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --no-update: 依存関係の自動的な更新を無効にします（--no-installを暗示します）。
  • --no-install: composer.lockを更新した後のインストール過程を走らせません。
  • --no-audit: composer.lockを更新した後の監査過程を走らせません。COMPOSER_NO_AUDITも参照してください。
  • --audit-format: 監査の出力形式です。 "table"、"plain"、"json"、または"summary"（既定）のどれかでなければなりません。
  • --update-no-dev: --no-devオプションと共に依存関係の更新を走らせます。COMPOSER_NO_DEVも参照してください。
  • --update-with-dependencies (-w): 新しく要求するパッケージの依存関係も更新します。 ただし根幹要件は除きます。 COMPOSER_WITH_DEPENDENCIES=1 環境変数でも設定できます。
  • --update-with-all-dependencies (-W): 新しく要求するパッケージの依存関係も更新します。 根幹要件も含まれます。 COMPOSER_WITH_ALL_DEPENDENCIES=1 環境変数でも設定できます。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視して、たとえローカルマシンが満たしていなかったとしても、インストールを強行します。 ワイルドカードを使って複数の要件を無視できます。
  • --prefer-stable: 依存関係の安定板を選ぶようにします。COMPOSER_PREFER_STABLE=1環境変数を介しても設定できます。
  • --prefer-lowest: 依存関係の最も低いバージョンを選ぶようにします。最小バージョン要件を試す際に便利で、一般的には--prefer-stableと共に使われます。COMPOSER_PREFER_LOWERST=1環境変数を介しても設定できます。
  • --minimal-changes (-m): -w / -Wでの更新の際に、遷移的な依存関係に関して絶対に必須の変更のみを実施するようにします。 COMPOSER_MINIMAL_CHANGES=1環境変数を介して設定することもできます。
  • --sort-packages: パッケージをpackage.jsonで整列した状態にします。
  • --optimize-autoloader (-o): PSR-0自動読み込みをクラスマップに変換して、より高速な自動読み込み器を取得します。 特に実運用で推奨されますが、走らせるのに少し時間が掛かるため、現時点では既定では有効になっていません。
  • --classmap-authoritative (-a): クラス対応表からクラスのみを自動読み込みします。 暗黙裡に--optimize-autoloaderを有効にします。
  • --apcu-autoloader: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-autoloader-prefix: APCu自動読み込み器のキャッシュ用に独自の接頭辞を使います。 暗黙裡に--apcu-autoloaderを有効にします。

remove / rm / uninstall

removeコマンドは現在のディレクトリにあるcomposer.jsonファイルからパッケージを削除します。

php composer.phar remove vendor/package vendor/package2

要件を削除した後は変更対象の要件がアンインストールされます。

オプション

  • --unused（もう）直接ないし間接の依存関係ではない、使われていないパッケージを削除します。
  • --dev: require-devからパッケージを削除します。
  • --dry-run: 実際には何もせず、コマンドを模擬します。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --no-update: 依存関係の自動的な更新を無効にします（--no-installを暗示します）。
  • --no-install: composer.lockを更新した後のインストール過程を走らせません。
  • --no-audit: インストールが完了した後の監査過程を走らせないようにします。 COMPOSER_NO_AUDITも参照してください。
  • --audit-format: 監査の出力形式です。 "table"、"plain"、"json"、または"summary"（既定）のどれかでなければなりません。
  • --update-no-dev: --no-devオプションで依存関係の更新を走らせます。COMPOSER_NO_DEVも参照してください。
  • --update-with-dependencies (-w): 削除されたパッケージの依存関係も更新します。 COMPOSER_WITH_DEPENDENCIES=1 環境変数でも設定できます（廃止されました。 現在は既定の挙動になっています）。
  • --update-with-all-dependencies (-W): 全ての継承する依存関係が更新されるようにします。 根幹要件のものも含みます。 COMPOSER_WITH_ALL_DEPENDENCIES=1 環境変数でも設定できます。
  • --minimal-changes (-m): -w / -Wでの更新の際に、遷移的な依存関係に関して絶対に必須の変更のみを実施するようにします。 COMPOSER_MINIMAL_CHANGES=1環境変数を介して設定することもできます。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視して、たとえローカルマシンが満たしていなかったとしても、インストールを強行します。 ワイルドカードを使って複数の要件を無視できます。
  • --optimize-autoloader (-o): PSR-0の自動読み込みをクラス対応表に変換して自動読み込みを高速にします。 実運用では特にお勧めしますが、走らせるのに少し時間が掛かることがあるので、現在は既定ではされません。
  • --classmap-authoritative (-a): クラス対応表からクラスのみを自動読み込みします。 暗黙裡に--optimize-autoloaderを有効にします。
  • --apcu-autoloader: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-autoloader-prefix: APCu自動読み込み器のキャッシュ用に独自の接頭辞を使います。 暗黙裡に--apcu-autoloaderを有効にします。

bump

bumpコマンドはcomposer.jsonの要件の下限を現在インストールされているバージョンに引き上げます。これにより依存関係が何らかの競合によりうっかりダウングレードされてしまわないようになったり、Composerが探すパッケージのバージョンの数が抑えられるため依存関係解決を僅かに向上させられます。

許される依存関係を狭めてしまうため、ライブラリでこれを無闇に走らせるのは推奨されません。 依存関係を狭めることは利用者に依存関係地獄を招きかねません。 しかしライブラリで--dev-onlyを走らせるのは、開発用要件がライブラリに対して局所的で、パッケージの消費者には影響しないため問題ないでしょう。

オプション

  • --dev-only: "require-dev" 中の要件のみbumpします。
  • --no-dev-only: "require" にある要件のみbumpします。
  • --dry-run: bumpするパッケージを出力しますが、何も実行しません。

reinstall

reinstallコマンドは名前からインストールされているパッケージを見付けだし、アンインストールと再インストールをします。 こうすることでファイルを散らかしたり--prefer-installを使ってインストールの種類を変えたいと思ったりしたときにクリーンインストールできます。

php composer.phar reinstall acme/foo acme/bar

再インストールするパッケージ名を1つ以上指定できます。 またはワイルドカードを使って複数パッケージの一括選択もできます。

php composer.phar reinstall "acme/*"

オプション

  • --prefer-install: パッケージをダウンロードする方法はsourceとdistの2つあります。 Composerはdistを既定で使います。 --prefer-install=source（または--prefer-source）を渡すと、Composerは、もしあればsourceからインストールします。 プロジェクトへのバグ修正をして、依存関係のローカルgitクローンを直接取得したい場合に便利です。 Composerがパッケージの開発版用のsourceを自動的に使う、以前の挙動にしたければ、--prefer-install=autoを使ってください。 config.preferred-installも参照してください。 このフラグを渡すと、設定値より優先されます。
  • --no-autoloader: 自動読み込み器の生成を飛ばします。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --optimize-autoloader (-o): PSR-0の自動読み込みをクラス対応表に変換して自動読み込みを高速にします。 実運用では特にお勧めしますが、走らせるのに少し時間が掛かることがあるので、現在は既定ではされません。
  • --classmap-authoritative (-a): クラス対応表からクラスのみを自動読み込みします。 暗黙裡に--optimize-autoloaderを有効にします。
  • --apcu-autoloader: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-autoloader-prefix: APCu自動読み込み器のキャッシュ用に独自の接頭辞を使います。 暗黙裡に--apcu-autoloaderを有効にします。
  • --ignore-platform-reqs: 全てのプラットフォーム要件を無視します。 再インストールコマンド用の自動読み込み器の生成のときにのみ効果があります。
  • --ignore-platform-req: 特定のプラットフォーム要件を無視します。 再インストールコマンド用の自動読み込み器の生成のときにのみ効果があります。 複数の要件をワイルドカードで無視できます。

check-platform-reqs

check-platform-reqsコマンドはPHPと拡張のバージョンがインストールされているパッケージのプラットフォーム要件を満たしているかを確認します。 例えば実運用サーバーでインストール後に、プロジェクトを走らせるのに必要な全ての拡張があることを検証したいときに使えます。

updateやinstallとは異なり、このコマンドはconfig.platform設定を無視し、実際のプラットフォームパッケージを検査します。 そのため要求されているプラットフォーム依存関係があることを確かめられます。

オプション

  • --lock: インストールされたパッケージからではなく、固定ファイルのみから要件を検査します。
  • --no-dev: require-devのパッケージ要件の検査を無効にします。
  • --format (-f): 出力の書式です。text（既定）またはjsonです。

global

globalコマンドはinstall、remove、require、updateのようなコマンドをあたかもCOMPOSER_HOMEディレクトリから走らせているように実行できます。

中心的な場所に保管されたプロジェクトを管理するためのただの補助であり、CLIツールやComposerプラグインのような、どこでも使えるようにしたいものを置いておけます。

大域的にCLIユーティリティをインストールするのに使えます。 以下は一例です。

php composer.phar global require friendsofphp/php-cs-fixer

これでphp-cs-fixerバイナリが大域的に使えるようになりました。大域的なベンダーバイナリディレクトリが$PATH環境変数の中にあるようにしてください。インストールした場所は以下のコマンドで得られます。

php composer.phar global config bin-dir --absolute

後になってバイナリを更新したいと思ったら、global updateを走らせられます。

php composer.phar global update

searchコマンドを使うと、現在のプロジェクトのパッケージリポジトリ全体を検索できます。 大抵はpackagistです。 検索したい用語を渡せます。

php composer.phar search monolog

複数の引数を渡すことで1つ以上の用語を探すこともできます。

オプション

  • --only-name (-N): パッケージの名前のみから検索します。
  • --only-vendor (-O): ベンダー・組織名のみから検索します。 結果として「ベンダー」のみが返ります。
  • --type (-t): 特定のパッケージの種類から探します。
  • --format (-f): text（既定）かjson出力かのどちらかを選べます。 jsonではname及びdescriptionキーのみが存在することが保証されています。 残り（url、repository、downloads、favers）はPackagist.orgの検索結果で得られるものであって、その他のリポジトリが返す情報はそれより多かったり少なかったりします。

show / info

使えるパッケージの全てを一覧にするにはshowコマンドが使えます。

php composer.phar show

一覧を絞り込むには、ワイルドカードを使ってパッケージマスクを渡せます。

php composer.phar show "monolog/*"

monolog/monolog 2.4.0 Sends your logs to files, sockets, inboxes, databases and various web services

何かのパッケージの詳細を見たければ、パッケージ名を渡すことができます。

php composer.phar show monolog/monolog

name     : monolog/monolog
descrip. : Sends your logs to files, sockets, inboxes, databases and various web services
keywords : log, logging, psr-3
versions : * 1.27.1
type     : library
license  : MIT License (MIT) (OSI approved) https://spdx.org/licenses/MIT.html#licenseText
homepage : http://github.com/Seldaek/monolog
source   : [git] https://github.com/Seldaek/monolog.git 904713c5929655dc9b97288b69cfeedad610c9a1
dist     : [zip] https://api.github.com/repos/Seldaek/monolog/zipball/904713c5929655dc9b97288b69cfeedad610c9a1 904713c5929655dc9b97288b69cfeedad610c9a1
names    : monolog/monolog, psr/log-implementation

support
issues : https://github.com/Seldaek/monolog/issues
source : https://github.com/Seldaek/monolog/tree/1.27.1

autoload
psr-4
Monolog\ => src/Monolog

requires
php >=5.3.0
psr/log ~1.0

パッケージのバージョンを渡すこともできます。 こうすると特定のバージョンでの詳細が分かります。

php composer.phar show monolog/monolog 1.0.2

オプション

  • --all: リポジトリで使える全てのパッケージを一覧にします。
  • --installed (-i): インストールされているパッケージを一覧にします（既定で有効になっており、時代遅れのオプションです）。
  • --locked: composer.lockから固定されたパッケージを一覧にします。
  • --platform (-p): プラットフォームパッケージ（phpと拡張）のみを一覧にします。
  • --available (-a): 利用できるパッケージのみにします。
  • --self (-s): 根幹パッケージ情報を一覧にします。
  • --name-only (-N): パッケージ名のみを一覧にします。
  • --path (-P): パッケージのパスを一覧にします。
  • --tree (-t): 依存関係を木構造で一覧にします。パッケージ名を渡した場合はそのパッケージの依存関係を示します。
  • --latest (-l): インストールされている全てのパッケージをその最新バージョンと共に一覧にします。
  • --outdated (-o): --latestを暗示しますが、新しいバージョンが手に入るパッケージのみを一覧にします。
  • --ignore: ワイルドカード (*) を含められます。 指定されたパッケージを無視します。 パッケージの新しいバージョンについて通知を受けたくなければ--outdatedオプションと一緒に使ってください。
  • --no-dev: パッケージ一覧から開発用の依存関係を除外します。
  • --major-only (-M): --latestまたは--outdatedと一緒に使ってください。 メジャーなセマンティックバージョニング互換の更新があるパッケージのみ示されます。
  • --minor-only (-m): --latestまたは--outdatedと一緒に使ってください。 マイナーなセマンティックバージョニング互換の更新があるパッケージのみ示されます。
  • --patch-only: --latestまたは--outdatedと一緒に使ってください。 パッチ水準のセマンティックバージョニング互換の更新があるパッケージのみが示されます。
  • --sort-by-age (-A): インストールされたバージョンの経過時間を表示し、古い順にパッケージを整列します。 --latestないし--outdatedオプションと一緒に使ってください。
  • --direct (-D): パッケージの一覧を直接的な依存関係に限定します。
  • --strict: 時代遅れのパッケージがあるときは非ゼロの終了コードを返します。
  • --format (-f): 出力形式としてtext（既定）ないしjsonを選びます。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、たとえローカルマシンがこれらの要件を満たしていなくても、インストールを強行します。--outdatedオプションと一緒に使ってください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、たとえローカルマシンがその要件を満たしていなくても、インストールを強行します。 ワイルドカードを介して複数の要件を無視できます。 --outdatedオプションと一緒に使ってください。

outdated

outdatedコマンドは、更新が利用できるインストール済みパッケージの一覧を、現在のバージョンと最新のバージョンを含めて示します。 基本的にcomposer show -loの別名になっています。

色彩コードは以下の通り。

  • green (=): 依存関係は最新バージョンであり、最新式です。
  • yellow (~): 依存関係に新しいバージョンが利用できるものがありますが、セマンティックバージョニングに於ける後方互換性の破壊が含まれます。 そのため更新できそうならしても良いですが、作業が発生する可能性があります。
  • red (!): 依存関係にセマンティックバージョニング上互換性のある新しいバージョンがあり、更新するべきです。

オプション

  • --all (-a): 時代遅れのものだけでなく、全てのパッケージを示します（composer show --latestの別名です）。
  • --direct (-D): パッケージの一覧を直接的な依存関係に限定します。
  • --strict: 1つもパッケージが時代遅れでなければ、非ゼロの終了コードを返します。
  • --ignore: 指定されたパッケージを無視します。 ワイルドカード (*) を含められます。 何かしらのパッケージの新しいバージョンについて知らされたくないときに使ってください。
  • --major-only (-M): メジャーなセマンティックバージョニング上の互換性を伴う更新のみ示します。
  • --minor-only (-m): マイナーなセマンティックバージョニング上の互換性を伴う更新のみ示します。
  • --patch-only (-p): パッチ水準のセマンティックバージョニング上の互換性を伴う更新のみ示します。
  • --sort-by-age (-A): インストールされたバージョンの経過時間を表示し、古い順にパッケージを整列します。
  • --format (-f): 出力形式としてtext（既定）ないしjsonを選びます。
  • --no-dev: 時代遅れの開発用依存関係を表示しません。
  • --locked: 固定ファイルを元にしたパッケージの更新を示します。 現在のベンダーディレクトリの中身は措かれます。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、たとえローカルマシンがこれらの要件を満たしていなくても、インストールを強行します。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視して、たとえローカルマシンが満たしていなかったとしても、インストールを強行します。 ワイルドカードを使って複数の要件を無視できます。

browse / home

browse（別名home）はパッケージのリポジトリURLまたはホームページをブラウザで開きます。

オプション

  • --homepage (-H): リポジトリではなくホームページのURLを開きます。
  • --show (-s): ホームページないしリポジトリのURLを表示するだけにします。

suggests

現在インストールされているパッケージの集合から提案される全てのパッケージを一覧にします。 おまけとして複数のパッケージ名をvendor/packageの形式で渡し、これらのパッケージのみについて提案を出力するように制限できます。

--by-package（既定）ないし--by-suggestionフラグを使って出力をグループ分けできます。それぞれ提案を行うパッケージによるグループ分けと提案されたパッケージによるグループ分けになっています。

提案されたパッケージ名の一覧だけが欲しければ--listを使ってください。

オプション

  • --by-package: 提案を行ったパッケージによって出力をグループ分けします（既定）。
  • --by-suggestion: 提案されたパッケージによって出力をグループ分けします。
  • --all: 推移的なものを含む全ての依存関係から提案を示します（既定では直接的な依存関係の提案のみが示されます）。
  • --list: 提案されたパッケージ名のみを一覧として示します。
  • --no-dev: require-devパッケージからの提案を除外します。

fund

依存関係の維持管理に投資して支援する方法が分かります。 このコマンドはインストールされている依存関係から全ての投資のリンクを一覧にします。 機械で読むことのできる出力を得るには--format=jsonを使ってください。

オプション

  • --format (-f): 出力形式としてtext（既定）ないしjsonを選びます。

depends / why

dependsコマンドは特定のパッケージに依存する他のパッケージを教えてくれます。 インストールの際、require-devの関係は根幹パッケージのみ考慮されます。

php composer.phar depends doctrine/lexer

doctrine/annotations  1.13.3 requires doctrine/lexer (1.*)
doctrine/common       2.13.3 requires doctrine/lexer (^1.0)

おまけとしてパッケージの後にバージョン制約を指定することで検索結果を絞り込むことができます。

--treeや-tフラグを加えると、なぜそのパッケージが依存されているのかの再帰的な木構造が示されます。例えば以下の通りです。

php composer.phar depends psr/log -t

psr/log 1.1.4 Common interface for logging libraries
├──composer/composer 2.4.x-dev (requires psr/log ^1.0 || ^2.0 || ^3.0)
├──composer/composer dev-main (requires psr/log ^1.0 || ^2.0 || ^3.0)
├──composer/xdebug-handler 3.0.3 (requires psr/log ^1 || ^2 || ^3)
│  ├──composer/composer 2.4.x-dev (requires composer/xdebug-handler ^2.0.2 || ^3.0.3)
│  └──composer/composer dev-main (requires composer/xdebug-handler ^2.0.2 || ^3.0.3)
└──symfony/console v5.4.11 (conflicts psr/log >=3) (circular dependency aborted here)

オプション

  • --recursive (-r): 再帰的に根幹パッケージまで木構造を解決します。
  • --tree (-t): 入れ子の木構造を結果に出力します。-rを暗示します。

prohibits / why-not

prohibitsコマンドを使うと与えられたパッケージがインストールされる上でどのパッケージが障壁になっているのかが分かります。 バージョン制約を指定するとプロジェクトにおいて更新が実施できるかを検証し、もしできなければその理由を示します。 以下の例をご覧ください。

php composer.phar prohibits symfony/symfony 3.1

laravel/framework v5.2.16 requires symfony/var-dumper (2.8.*|3.0.*)

なおプラットフォーム要件も指定できます。 例えばサーバーをPHP 8.0に更新できるかどうかを確認するにはこうします。

php composer.phar prohibits php 8

doctrine/cache        v1.6.0 requires php (~5.5|~7.0)
doctrine/common       v2.6.1 requires php (~5.5|~7.0)
doctrine/instantiator 1.0.5  requires php (>=5.3,<8.0-DEV)

dependsと同様に再帰的な探索を求めることができます。その場合は競合を起こしているパッケージに依存している全てのパッケージを一覧にします。

オプション

  • --recursive (-r): 再帰的に根幹パッケージまで木構造を解決します。
  • --tree (-t): 入れ子の木構造を結果に出力します。-rを暗示します。

validate

composer.jsonファイル（と、当てはまるときはcomposer.lock）をコミットしたり、リリースのタグ付けをしたりする前には、必ずvalidateコマンドを走らせるべきです。

composer.jsonが正当であるか検査します。 composer.lockがあるとき、composer.jsonに対して最新かも検査します。

php composer.phar validate

オプション

  • --no-check-all: composer.json中の要件が範囲のないものであったり、過度に厳密なバージョン制約であったりする場合について、警告を出しません。
  • --no-check-lock: composer.lockが存在し、且つ更新されていない場合について、警告を出しません。
  • --check-lock 固定ファイルが最新か検査します（config.lockが偽の場合も含みます）
  • --no-check-publish: Packagistに投稿するには相応しくないが、そうでなければ妥当なcomposer.jsonになっている場合について、エラーを出しません。
  • --no-check-version: バージョンフィールドがあるとき、警告を出しません。
  • --with-dependencies: 全てのインストールされた依存関係についてもcomposer.jsonを検証します。
  • --strict: エラーに加えて警告についても非ゼロの終了コードを返します。

status

依存関係のコードを変更したり、ソースからインストールしたりする必要がしばしばある場合は、statusコマンドを使うとその中からローカルで加えた変更があるか確認できます。

php composer.phar status

--verboseコマンドで変化したところについてのより詳しい情報を得られます。

php composer.phar status -v

You have changes in the following dependencies:
vendor/seld/jsonlint:
    M README.mdown

self-update / selfupdate

Composer自体を最新版に更新したければself-updateコマンドを走らせてください。composer.pharを最新版に置き換えます。

php composer.phar self-update

そうではなく特定のリリースに更新したければそのように指定してください。

php composer.phar self-update 2.4.0-RC1

Composerをシステム全体にインストールしたときは（大域的なインストールを参照）、コマンドをroot権限で走らせなくてはならないかもしれません。

sudo -H composer self-update

ComposerがPHARとしてインストールされていなければこのコマンドは使えません（Composerがオペレーティングシステムのパッケージ管理によってインストールされたときはこの場合に当たることがあります）。

オプション

  • --rollback (-r): インストールした直近のバージョンに巻き戻します。
  • --clean-backups: 更新時に古いバックアップを削除します。更新後は現在のComposerのバージョンのみがバックアップとして残ります。
  • --no-progress: ダウンロードの進捗バーを出力しません。
  • --update-keys: キーの更新を利用者に尋ねます。
  • --stable: 更新を安定チャンネルに強制します。
  • --preview: 更新をプレビューチャンネルに強制します。
  • --snapshot: 更新をスナップショットチャンネルに強制します。
  • --1: 更新を安定チャンネルに強制しますが、1.x版のみを使います。
  • --2: 更新を安定チャンネルに強制しますが、2.x版のみを使います。
  • --set-channel-only: チャンネルを既定のものとして保存するだけして終了します。

config

configコマンドではローカルのcomposer.jsonファイルまたは大域的なconfig.jsonファイルにあるComposerの設定やリポジトリを編集できます。

加えてローカルのcomposer.jsonにある殆どのプロパティを編集できます。

php composer.phar config --list

使い方

config [options] [setting-key] [setting-value1] ... [setting-valueN]

setting-keyは設定のオプション名で、setting-value1は設定値です。 （github-protocolsのような）値の配列を取ることができる設定については、複数の設定値の引数が可能です。

プロパティの値を編集することもできます。

description、homepage、keywords、license、minimum-stability、name、prefer-stable、type、versionがそうです。

妥当な設定オプションについては設定の章を参照してください。

オプション

  • --global (-g): 既定では$COMPOSER_HOME/config.jsonに位置する大域設定ファイルを編集します。 このオプションがなければ、このコマンドはローカルのcomposer.jsonファイルないし--file`により指定されたファイルに作用します。
  • --editor (-e): ローカルのcomposer.jsonファイルをEDITOR環境変数で定義されたテキストエディタを使って開きます。--globalオプションと一緒に使うと大域設定ファイルを開きます。
  • --auth (-a): 認証設定ファイルに作用します（--editorの使用限定です）。
  • --unset: setting-keyの名前が付いている設定要素を削除します。
  • --list (-l): 現在の設定変数の一覧を示します。globalオプションと一緒に使うと大域設定のみを一覧にします。
  • --file="..." (-f): composer.jsonではなく特定のファイルについて編集します。 なお、--globalオプションと織り交ぜて使うことはできません。
  • --absolute: *-dir設定値を取得するとき、相対パスではなく絶対パスを返します。
  • --json: 設定値をJSONでデコードします。このデコード結果はextra.*キーで使うことができます。
  • --merge: 設定値を現在の値と統合します。--jsonと組み合わせてextra.*キーに使えます。
  • --append: リポジトリを追加するとき、既存のものの先頭に追加する（最優先）のではなく末尾に付ける（低優先）ようにします。
  • --source: 設定値がどこから読み込まれたのかを表示します。

リポジトリを変更する

設定部分を変更することに加えて、configコマンドを以下のように使うことでリポジトリ部分を変更することにも対応しています。

php composer.phar config repositories.foo vcs https://github.com/foo/bar

リポジトリにより多くの設定オプションが必要なら、代わりにそのJSON表現を渡すことができます。

php composer.phar config repositories.foo '{"type": "vcs", "url": "http://svn.example.org/my-project/", "trunk-path": "master"}'

追加の値を変更する

設定部分を変更することに加えて、configコマンドを以下のように使って追加部分を変更することにも対応しています。

php composer.phar config extra.foo.bar value

ドットは入れ子の連なりを表していますが、深さは3段階までです。上は"extra": { "foo": { "bar": "value" } }を設定します。

複雑な値を加えたり変更したりする場合は--jsonや--mergeフラグを使って追加のフィールドをJSONとして編集できます。

php composer.phar config --json extra.foo.bar '{"baz": true, "qux": []}'

create-project

Composerを使って既存のパッケージから新しいプロジェクトを作ることができます。 git cloneやsvn checkoutをしてから、ベンダーにあるものをcomposer installすることと等価です。

このコマンドにはいくつかの活用法があります。

  1. アプリケーションパッケージをデプロイできます。
  2. 任意のパッケージをチェックアウトして、例えばパッチを開発できます。
  3. 複数人の開発者がいるプロジェクトでこの機能を使い、開発のための初期のアプリケーションに着手できます。

Composerで新しいプロジェクトを作るためにはcreate-projectコマンドが使えます。パッケージ名とプロジェクトを作成するディレクトリを渡してください。また、3つ目の引数としてバージョンを与えることもでき、与えない場合は最新版が使われます。

ディレクトリがその時点で存在しなければインストールの過程で作られます。

php composer.phar create-project doctrine/orm path "2.2.*"

プロジェクトに着手するための既存のcomposer.jsonがあるディレクトリ内では、引数がなくともコマンドを走らせることができます。

既定ではコマンドはパッケージをpackagist.orgで確認します。

オプション

  • --stability (-s): パッケージの最小安定性です。stableが既定です。
  • --prefer-install: パッケージをダウンロードする方法はsourceとdistの2つあります。 Composerはdistを既定で使います。 --prefer-install=source（または--prefer-source）を渡すと、Composerは、もしあればsourceからインストールします。 プロジェクトへのバグ修正をして、依存関係のローカルgitクローンを直接取得したい場合に便利です。 Composerがパッケージの開発版用のsourceを自動的に使う、以前の挙動にしたければ、--prefer-install=autoを使ってください。 config.preferred-installも参照してください。 このフラグを渡すと、設定値より優先されます。
  • --repository: パッケージを探索するための独自のリポジトリを与えます。このリポジトリはpackagistの代わりに使われます。composerディレクトリを指すHTTP URLでも、ローカルのpackages.jsonファイルへのパスでも、あるいはリポジトリキーが受け付けるものに似たJSON文字列でも大丈夫です。複数回使って複数のリポジトリを設定できます。
  • --add-repository: composer.jsonの中に独自のリポジトリを加えます。 固定ファイルが存在している場合、一旦削除されインストールの代わりに更新が走ります。
  • --dev: require-devに挙げられたパッケージをインストールします。
  • --no-dev: require-devのパッケージのインストールを無効にします。
  • --no-scripts: 根幹パッケージで定義されているスクリプトの実行を無効にします。
  • --no-progress: 進捗表示を除きます。 バックスペース文字を扱わない端末やスクリプトではこの表示があることで散らかってしまうからです。
  • --no-secure-http: 根幹パッケージのインストール中、一時的にsecure-http設定オプションを無効にします。 自己責任でご利用ください。 このフラグを使うのは関心しません。
  • --keep-vcs: 作成されるプロジェクトのVCSメタデータの削除を飛ばします。 これが役に立つのはコマンドを非対話的なモードで走らせているときが殆どです。
  • --remove-vcs: プロンプト無しにVCSメタデータを強制削除します。
  • --no-install: ベンダーのインストールを無効にします。
  • --no-audit: インストールが完了した後の監査過程を走らせないようにします。 COMPOSER_NO_AUDITも参照してください。
  • --audit-format: 監査の出力形式です。 "table"、"plain"、"json"、または"summary"（既定）のどれかでなければなりません。
  • --ignore-platform-reqs: 全てのプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、ローカルマシンがたとえこれらを満たしていなくてもインストールを強行します。 platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視して、たとえローカルマシンが満たしていなかったとしても、インストールを強行します。 ワイルドカードを使って複数の要件を無視できます。
  • --ask: 利用者に新しいプロジェクトの対象ディレクトリを入れてもらうようにします。

dump-autoload / dumpautoload

例えばクラスマップパッケージ中に新しいクラスができたことによって自動読み込み器を更新する必要がある場合は、インストールや更新を行わずともdump-autoloadが使えます。

加えて、効率性の理由からPSR-0/4のパッケージをクラスマップのものに変換する、最適化された自動読み込み器を吐き出すことができます。 多くのクラスがある比較的大規模なアプリケーションでは、自動読み込み器には毎回のリクエストに掛かる時間のうち無視できない時間が掛かります。 開発時に常にクラスマップを使うことはあまり便利ではありませんが、このオプションを使えば便宜上PSR-0/4を使いつつも、効率性のためにクラスマップを使うことができます。

オプション

  • --optimize (-o): PSR-0/4自動読み込みをクラスマップに変換し、より高速な自動読み込み器を得ます。 実運用で特に推奨されますが、走らせるのに少し時間が掛かるため、現時点では既定で有効になっていません。
  • --classmap-authoritative (-a): クラスマップからのみクラスを自動読み込みします。暗に--optimizeを有効します。
  • --apcu: APCuを使って、クラスの有無をキャッシュします。
  • --apcu-prefix: APCu自動読み込み器のキャッシュに独自の接頭辞を使います。暗に--apcuを有効にします。
  • --dry-run: 操作内容を出力しますが、何も実行しません。
  • --no-dev: autoload-dev規則を無効にします。 既定では、Composerは直近のinstall --no-devまたはupdate --no-devの状態に随って自動的にこれを推測します。
  • --dev: autoload-dev規則を有効にします。 既定では、Composerは直近のinstall --no-devまたはupdate --no-devの状態に随って自動的にこれを推測します。
  • --ignore-platform-reqs: 全てのphp、hhvm、lib-*、ext-*要件を無視し、これらのプラットフォーム検査を飛ばします。platform設定オプションも参照してください。
  • --ignore-platform-req: 特定のプラットフォーム要件（php、hhvm、lib-*、ext-*）を無視し、それについてのプラットフォーム検査を飛ばします。 ワイルドカードを使って複数の要件を無視できます。
  • --strict-psr: PSR-4またはPSR-0の対応付けでの失敗が存在する場合は、失敗の終了コード (1) を返します。 動作には--optimizeが必要です。
  • --strict-ambiguous: 複数ファイルに同じクラスがあるとき、失敗の終了コード (2) を返します。 動作には--optimizeが必要です。

clear-cache / clearcache / cc

Composerのキャッシュディレクトリから全ての内容を削除します。

オプション

  • --gc: ガベージコレクションのみを走らせます。完全なキャッシュの消去は行いません。

licenses

インストールされている全てのパッケージの名前、バージョン、使用許諾を一覧にします。 --format-jsonを使うと、機械で読み込みやすい出力が得られます。

オプション

  • --format: 出力の形式です。text、json、summaryの何れかです（既定では「text」）。
  • --no-dev: 出力から開発依存関係を除きます。

run-script / run

オプション

  • --timeout: スクリプトの制限時間を秒単位で設定します。0は制限時間無しです。
  • --dev: 開発モードを設定します。
  • --no-dev: 開発モードを無効にします。
  • --list (-l): 利用者が定義したスクリプトを一覧にします。

スクリプトを手動で走らせるにはこのコマンドを使うことができます。スクリプト名と任意で必要な引数を与えます。

exec

ベンダーのバイナリやスクリプトを実行します。 どんなコマンドも実行できますし、コマンドが走る前に必ずComposerのbin-dirがPATHに加えられます。

オプション

  • --list (-l): 利用できるComposerのバイナリを一覧にします。

diagnose

バグや奇妙な挙動を発見したと思ったら、diagnoseコマンドを走らせて、多くのよくある問題について自動化された検査を実施できます。

php composer.phar diagnose

archive

このコマンドを使うと、与えられたバージョンの与えられたパッケージについてzip/tarアーカイブを生成します。 除外・無視対象のファイルを除く、プロジェクト全体をアーカイブするために使うこともできます。

php composer.phar archive vendor/package 2.0.21 --format=zip

オプション

  • --format (-f): アーカイブ結果の形式です。tar、tar.gz、tar.bz2、zipのいずれかです（既定：「tar」）。
  • --dir: アーカイブをこのディレクトリに書き出します（既定：「.」）。
  • --file: 与えられたファイル名でアーカイブを書き出します。

audit

このコマンドを使うと、インストールしたパッケージに対し、セキュリティ上の問題がありうるか監査できます。 既定ではPackagist.org apiを使い、セキュリティ上の脆弱性に対する推奨事項を確認して一覧にします。 composer.jsonのrepositories節で指定されたときは、他のリポジトリが使われます。 このコマンドでは、放棄されたパッケージも検出されます。

監査コマンドでは、脆弱なパッケージや放棄されたパッケージがあるか判定されます。 見つかったものに基づいて、以下の終了コードを返します。

  • 0 は、問題なし
  • 1 は、脆弱なパッケージ
  • 2 は、放棄されたパッケージ
  • 3 は、脆弱なパッケージと放棄されたパッケージ
php composer.phar audit

オプション

  • --no-dev: require-devのパッケージの監査を無効にします。
  • --format (-f): 出力の形式を監査します。監査の出力は「table」（既定）、「plain」、「json」、「summary」の何れかです。
  • --locked: 固定ファイルのパッケージを監査します。 現時点でベンダーディレクトリに何があるかは無視されます。
  • --abandoned: 放棄されたパッケージに対して動作します。 「ignore」「report」「fail」のどれかでなければなりません。 audit.abandonedもご参照ください。 このフラグを渡すと、構成値と環境変数がオーバーライドされます。
  • --ignore-severity: 特定の深刻度の水準の勧告を無視します。 複数の深刻度を無視するために1回以上渡せます。

help

あるコマンドについて詳細が知りたければhelpが使えます。

php composer.phar help install

コマンドラインインターフェース

コマンドライン補完は、composer completion --helpコマンドを走らせると有効にできます。 また、以下の手順に従ってください。

環境変数

環境変数を設定して多くの設定を上書きできます。 できる限りこうした設定は環境変数ではなくcomposer.jsonのconfig部分で指定することをお勧めします。 環境変数はcomposer.jsonで指定された値より常に優先されるということ以外に利点はありません。

COMPOSER

COMPOSER環境変数を設定することにより、composer.jsonのファイル名を何か別のものに設定できます。

例えば：

COMPOSER=composer-other.json php composer.phar install

生成される固定ファイルは同じ名前を使います。 この例ではcomposer-other.lockです。

COMPOSER_ALLOW_SUPERUSER

1に設定すると、この環境変数はコマンドをルートないし特権のある利用者として走らせることについての警告を無効にします。 自動的なsudoセッションの消去も無効にするため、必ずDockerコンテナのような特権のある利用者として、常時Composerを使うときにのみ設定するようにしてください。

COMPOSER_ALLOW_XDEBUG

1に設定すると、Xdebug拡張を持たないPHPを再始動させることなく、環境変数はXdebug拡張が有効のときにComposerを走らせられるようにします。

COMPOSER_AUTH

COMPOSER_AUTH変数では、環境変数として認証を設定できます。 変数の内容はJSON形式のオブジェクトで、http-basic、github-oauth、bitbucket-oauth、……といった必要に応じたものです。 オブジェクトは設定の仕様に従います。

COMPOSER_BIN_DIR

このオプションを設定するとbinディレクトリ（ベンダーバイナリ）をvendor/binとは違う別のどこかに変更できます。

COMPOSER_CACHE_DIR

COMPOSER_CACHE_DIR変数ではComposerのキャッシュディレクトリを変更できます。 cache-dirオプションを介しても設定できます。

Windowsにおいて既定ではC:\Users\<user>\AppData\Local\Composer（もしくは%LOCALAPPDATA%/Composer）を指します。 *nixシステムではXDG Base Directory Specificationsに従い、$XDG_CACHE_HOME/composerを指します。他の*nixシステムとmacOSにおいては$COMPOSER_HOME/cacheを指します。

COMPOSER_CAFILE

この環境値を設定することで、パスを証明書バンドルファイルに設定してSSL/TLSピア検証で使えるようにします。

COMPOSER_DISABLE_XDEBUG_WARN

1に設定すると、ComposerがXdebug拡張が有効の状態で走っているときに出す警告をこの環境変数により抑制します。

COMPOSER_DISCARD_CHANGES

この環境変数はdiscard-changes設定オプションを制御します。

COMPOSER_FUND

この環境変数を0に設定すると、インンストール時に投資のお知らせを抑制します。

COMPOSER_HOME

COMPOSER_HOME変数によりComposerのホームディレクトリを変えられます。 全てのプロジェクトで共有される、隠された（マシン上の使用者毎の）大域的なディレクトリです。

composer config --global homeを使ってホームディレクトリの場所を確認してください。

既定では、WindowsにおいてはC:\Users\<user>\AppData\Roaming\Composerを、macOSにおいては/Users/<user>/.composerを指します。*nixシステムではXDG Base Directory Specificationsに従い、$XDG_CONFIG_HOME/composerを指します。他の*nixシステムでは/home/<user>/.composerを指します。

COMPOSER_HOME/config.json

config.jsonファイルをCOMPOSER_HOMEが指す場所に置くことができます。Composerはinstall及びupdateコマンドを走らせたとき、部分的に（configおよびrepositoriesキーのみ）この設定をプロジェクトのcomposer.jsonと統合します。

このファイルがあれば使用者のプロジェクト用にリポジトリと構成を設定できます。

大域的な設定がローカルの設定に合致した場合、プロジェクトのcomposer.jsonが常に優先されます。

COMPOSER_HTACCESS_PROTECT

既定では1です。0に設定するとComposerはComposerのホーム、キャッシュ、データディレクトリに.htaccessファイルを作りません。

COMPOSER_MEMORY_LIMIT

設定すると、その値がphpのメモリ上限として使われます。

COMPOSER_MIRROR_PATH_REPOS

1に設定すると、この環境変数は既定のパスリポジトリ戦略をsymlinkではなくmirrorに変更します。既定の戦略が設定されているため、リポジトリオプションで上書きすることもできます。

COMPOSER_NO_INTERACTION

1に設定すると、この環境変数によりComposerがあたかも全てのコマンドについて--no-interactionフラグを渡されたかのように動作します。 build box/CIで設定できます。

COMPOSER_PROCESS_TIMEOUT

この環境変数はコマンド（例えばgitコマンド）が実行終了するまでの待機時間を制御します。既定値は300秒（5分）です。

COMPOSER_ROOT_VERSION

この変数を設定することで、根幹パッケージのバージョンがVCSの情報から推測できず、composer.jsonにもないときに、そのバージョンを指定できます。

COMPOSER_VENDOR_DIR

この変数を設定することでComposerに依存関係をvendor以外のディレクトリにインストールさせられます。

COMPOSER_RUNTIME_ENV

これによりどの環境でComposerが走っているのかの手掛かりが得られ、Composerで何らかの環境特有の問題を回避するための助けになります。 現在対応している唯一の値はvirtualboxで、こうするといくつかの短いsleep()呼び出しを有効にして、ファイルシステムが適切にファイルに書き込むのを待ってからそのファイルを読み込むようにします。 VagrantやVirtualboxを使っていてファイルが存在しているのにも関わらずインストール時にファイルがない旨問題に遭遇したときは、この環境変数を設定すると良いでしょう。

http_proxyやHTTP_PROXY

HTTP_PROXY_REQUEST_FULLURI

HTTPS_PROXY_REQUEST_FULLURI

no_proxyやNO_PROXY

プロキシの環境変数の使い方についての詳細は、プロキシのドキュメントを参照してください。

COMPOSER_AUDIT_ABANDONED

ignore、report、failに設定すると、audit.abandoned構成オプションをオーバーライドします。

COMPOSER_MAX_PARALLEL_HTTP

整数を指定し、並列で何個のファイルをダウンロードするか設定します。 既定で12になっており、1から50の間でなければいけません。 プロキシに並列性の問題があるときはこの値を下げたいかもしれません。 この値を増加させても一般には効率性が上がる結果にはならないでしょう。

COMPOSER_MAX_PARALLEL_PROCESSES

整数を設定し、並列でいくつのプロセスを実行できるか構成します。 既定では10で、1と50の間でなければなりません。

COMPOSER_IPRESOLVE

4ないし6に設定するとそれぞれIPv4ないしIPv6の解決を強制します。 ダウンロード用にcurl拡張が使用されている場合にのみ機能します。

COMPOSER_SELF_UPDATE_TARGET

設定した場合、self-updateコマンドが元あるファイルではなく与えられたパスに新しいComposerのpharファイルを書き込むようにします。読み込み専用のファイルシステムでComposerを更新するときに便利です。

COMPOSER_DISABLE_NETWORK

1に設定するとネットワークアクセスを（最大限の努力で）無効にします。この変数はComposerをデバッグしたり貧弱な接続環境下で走らせたりするのに使えます。

primeに設定した場合、GitHub VCSリポジトリはキャッシュに前もって溜め込んでおくため、1で完全にオフラインで使えるようになります。

COMPOSER_DEBUG_EVENTS

1に設定するとディスパッチされたイベントについての情報を出力します。プラグインの作者にとって何が厳密にどの時点で発火しているのか特定するのに便利かもしれません。

COMPOSER_SKIP_SCRIPTS

イベント名のコンマ区切りリストを受け付けます。 例えば、スクリプト実行をスキップするためのpost-install-cmdがあります。

COMPOSER_NO_AUDIT

1に設定すると、require、update、remove、create-projectコマンドに--no-auditコマンドを渡すことと等価になります。

COMPOSER_NO_DEV

1に設定すると--update-no-devをrequireに渡したりinstall、updateに--no-devオプションを渡すのと等価になります。 COMPOSER_NO_DEV=0を設定することで1回のコマンドについてこの設定を上書きできます。

COMPOSER_PREFER_STABLE

1に設定するとupdateやrequireに--prefer-stableオプションを渡すことと等価になります。

COMPOSER_PREFER_LOWEST

1に設定するとupdateやrequireに--prefer-lowestオプションを渡すことと等価になります。

COMPOSER_MINIMAL_CHANGES

1に設定すると、updateやrequireやremoveに--minimal-changesオプションを渡すことと等価になります。

COMPOSER_IGNORE_PLATFORM_REQやCOMPOSER_IGNORE_PLATFORM_REQS

COMPOSER_IGNORE_PLATFORM_REQSを1に設定すると、--ignore-platform-reqs引数を渡すことと等価になります。 他方でCOMPOSER_IGNORE_PLATFORM_REQでコンマ区切りのリストを指定すると、これらの特定の要件を無視します。

例えば開発ワークステーションが全くデータベースクエリを走らせない場合、データベースの要件が利用できることの要件を無視するのに使うことができます。COMPOSER_IGNORE_PLATFORM_REQ=ext-oci8を設定すると、Composerはoci8PHP拡張が有効になっていなくともパッケージをインストールします。

COMPOSER_WITH_DEPENDENCIES

1に設定すると、updateやrequireやremoveに、--with-dependenciesオプションを渡すことと同じです。

COMPOSER_WITH_ALL_DEPENDENCIES

1に設定すると、updateやrequireやremoveに、--with-all-dependenciesオプションを渡すことと同じです。

← ライブラリ | スキーマ →

composer.jsonのスキーマ

この章ではcomposer.jsonで利用できる全てのフィールドについて説明します。

JSONスキーマ

形式をドキュメント化するJSON schemaがあり、composer.jsonを検証するのにも使えます。実際、validateコマンドによって使われています。 https://getcomposer.org/schema.json から取得できます。

根幹パッケージ

根幹パッケージとは、composer.jsonでプロジェクトの根幹に定義されたパッケージのことです。 プロジェクトの要件を定義しているのが主眼のcomposer.jsonなのです。

フィールドの中には根幹パッケージの文脈でのみ適用されるものがあります。 この一例はconfigフィールドです。 根幹パッケージのみが設定を定義できます。 依存関係の設定は無視されます。 このようにしてconfigフィールドはroot-onlyになるのです。

補足： パッケージは文脈によって根幹パッケージになったりならなかったりします。 例えばプロジェクトがmonologライブラリに依存している場合、そのプロジェクトは根幹パッケージです。 しかしもし不具合修正のためにGitHubからmonologをクローンしてきたとすれば、monologが根幹パッケージになります。

プロパティ

name

パッケージ名です。ベンダー名とプロジェクト名から構成され、/で区切られます。例えば：

  • monolog/monolog
  • igorw/event-source

名前は小文字で、単語は-や.や_で区切られていなくてはなりません。 名前全体は^[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9](([_.]|-{1,2})?[a-z0-9]+)*$に照合します。

nameプロパティは公開されるパッケージ（ライブラリ）には必須です。

補足： Composerのバージョン2.0より前は、名前には空白込みでどんな文字も含められました。

description

パッケージの短い説明です。 大抵1行分の長さです。

公開されるパッケージ（ライブラリ）には必須です。

version

パッケージのバージョンです。 殆どの場合は必須でなく、省略すべきです（後述）。

X.Y.ZやvX.Y.Zの形式に従っていなければなりません。 オプションで-dev、-patch (-p)、-alpha (-a)、-beta (-b)、-RCを接尾辞に付けても構いません。 また、patch、alpha、beta、RCの接尾辞には数字を続けても大丈夫です。

例：

  • 1.0.0
  • 1.0.2
  • 1.1.0
  • 0.2.5
  • 1.0.0-dev
  • 1.0.0-alpha3
  • 1.0.0-beta2
  • 1.0.0-RC5
  • v2.0.4-p1

パッケージのリポジトリのどこかしらからバージョンが推測できるのであれば、このプロパティはオプションです。 例えばVCSリポジトリのVCSのタグ名などです。 その場合は省略することが推奨されます。

補足： PackagistはVCSリポジトリを使うため、上の記載はPackagistにも全く同じことが言えます。 自分でバージョンを指定すると、ほぼ確実にいつか手作業による誤りにより問題が生じることでしょう。

type

パッケージの種別です。既定はlibraryです。

パッケージの種別は独自のインストールの仕組みに使われます。 何らかの特別な仕組みが必要なパッケージがあるとき、symfony-bundle、wordpress-plugin、typo3-cms-extensionといった独自の種別を定義できます。 これらの種別は全て特定のプロジェクトに特有のものであって、その種別のパッケージのインストールができるようなインストーラを提供する必要があります。

その中でも特にComposerは4つの種別に対応しています。

  • library: 既定です。 ファイルをvendorに複製します。
  • project: ライブラリではなくプロジェクトであることを示します。 例えば標準版Symfonyのようなアプリケーションのシェル、SilverstripeインストーラのようなCMS、あるいはパッケージとして配布される完全なアプリケーションがこれにあたります。 例として、IDEから新しいワークスペースを作る際に、初期化するプロジェクトの一覧を提供するのに使えます。
  • metapackage: 要件を含む空のパッケージでありインストールの条件になりますが、ファイルを含んでおらずファイルシステムに何も書き込まないものです。 そうしたわけで、インストールできるdistやsourceキーを必要としません。
  • composer-plugin: 種別composer-pluginのパッケージは独自の種別を持つ他のパッケージのインストーラを提供することがあります。 詳細は専門記事を参照してください。
  • php-extとphp-ext-zend： これらの名前はCで書かれたPHPの拡張パッケージ用に予約されています。 これらの種別はPHPで書かれたパッケージ用に使わないでください。

インストール時に独自の仕組みが必要な場合にのみ独自の種別を使ってください。 このフィールドを省略し、既定のlibraryにするのがお勧めです。

keywords

パッケージに関係するキーワードの配列です。検索と絞り込みに使えます。

例：

  • logging
  • events
  • database
  • redis
  • templating

補足：--devオプション無しでcomposer requireするようにし、パッケージをrequireではなくrequire-devに追加しても良いか利用者にプロンプトを出す特別なキーワードがあります。 dev、testing、static analysisがそれです。

補足：文字列内で許される文字の範囲には、ユニコードの英数字、空白" "、ドット.、下線_、ダッシュ-（正規表現：'{^[\p{N}\p{L} ._-]+$}u'）の制限があります。 その他の文字を使うと、composer validateを走らせるときに警告が出ます。 またパッケージのPackagist.orgへの更新が失敗する原因となります。

省略可能です。

homepage

プロジェクトのwebサイトへのURLです。

省略可能です。

readme

readmeドキュメントへの相対パスです。 既定ではREADME.mdです。

主にパッケージがGitHubにないときに有用です。 GitHubのパッケージの場合、Packagist.orgではGitHub側で検出されたものを取得するreadme APIを使うからです。

省略可能です。

time

当該バージョンのリリース日です。

YYYY-MM-DDまたはYYYY-MM-DD HH:MM:SSの形式で、UTCタイムゾーンでなければなりません。

省略可能です。

license

パッケージの利用許諾です。 文字列または文字列の配列にできます。

最頻出の利用許諾についての推奨される記法は以下の通り（辞書順）。

  • Apache-2.0
  • BSD-2-Clause
  • BSD-3-Clause
  • BSD-4-Clause
  • GPL-2.0-only / GPL-2.0-or-later
  • GPL-3.0-only / GPL-3.0-or-later
  • LGPL-2.1-only / LGPL-2.1-or-later
  • LGPL-3.0-only / LGPL-3.0-or-later
  • MIT

オプションにはなりますが、このプロパティを付けることは強く推奨されます。他の識別子はSPDX Open Source License Registryに一覧になっています。

Note: ソースが閉鎖的なソフトウェアについては、利用許諾の識別子として "proprietary" を使うことができます。

一例：

{
    "license": "MIT"
}

あるパッケージについて、複数の利用許諾から選択できる場合（「離接的利用許諾」）、複数のものを配列として指定できます。

離接的利用許諾の例です。

{
    "license": [
        "LGPL-2.1-only",
        "GPL-3.0-or-later"
    ]
}

代わりに「or」で区切って括弧で囲むこともできます。

{
    "license": "(LGPL-2.1-only or GPL-3.0-or-later)"
}

これに似ていますが、複数の利用許諾が適用される必要があるときは（「結合的利用許諾」）、「and」で区切って（）で囲むことになります。

authors

パッケージの作者です。 オブジェクトの配列です。

それぞれの作者オブジェクトは以下のプロパティを持つことができます。

  • name: 作者名です。大抵は実名です。
  • email: 作者のEメールアドレスです。
  • homepage: 作者のwebサイトへのURLです。
  • role: プロジェクトに於ける作者の役割です（例：開発者や翻訳者）

一例：

{
    "authors": [
        {
            "name": "Nils Adermann",
            "email": "naderman@naderman.de",
            "homepage": "https://www.naderman.de",
            "role": "Developer"
        },
        {
            "name": "Jordi Boggiano",
            "email": "j.boggiano@seld.be",
            "homepage": "https://seld.be",
            "role": "Developer"
        }
    ]
}

省略可能なプロパティですが、付けることを強く推奨します。

support

プロジェクトについてのサポートを得るための様々な情報です。

サポート情報には以下が含まれます。

  • email: サポート用Eメールアドレスです。
  • issues: 課題管理表へのURLです。
  • forum: フォーラムへのURLです。
  • wiki: wikiへのURLです。
  • irc: irc://server/channelのような、サポート用IRCチャンネルです。
  • source: ソースを閲覧したりダウンロードしたりするURLです。
  • docs: ドキュメントへのURLです。
  • rss: RSSフィードへのURLです。
  • chat: チャットチャンネルへのURLです。
  • security: 脆弱性公表ポリシー (vulnerability disclosure policy; VDP) へのURLです。

一例：

{
    "support": {
        "email": "support@example.org",
        "irc": "irc://irc.freenode.org/composer"
    }
}

省略可能です。

funding

パッケージの作者が維持管理と新しい機能の開発を行えるよう、投資を提供するためのURLの一覧です。

それぞれの項目は以下のものからなります。

  • type: 投資の種別、または投資を行えるプラットフォームです。例えばpatreon、opencollective、tidelift、githubです。
  • url: 詳細が記載されたwebサイトへのURLと、パッケージに投資する方法です。

一例：

{
    "funding": [
        {
            "type": "patreon",
            "url": "https://www.patreon.com/phpdoctrine"
        },
        {
            "type": "tidelift",
            "url": "https://tidelift.com/subscription/pkg/packagist-doctrine_doctrine-bundle"
        },
        {
            "type": "other",
            "url": "https://www.doctrine-project.org/sponsorship.html"
        }
    ]
}

省略可能です。

パッケージのリンク

以下の全ては、バージョン制約を介してパッケージ名とパッケージのバージョンを対応付けるオブジェクトを取ります。 バージョンについての詳細はこちらをお読みください。

例：

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

全てのリンクは省略可能なフィールドです。

requireとrequire-devは追加で安定性フラグ（根幹限定）に対応しています。 "constraint@stability flag" の形式を取っています。 これらによりパッケージの安定性を、最小安定性の範疇を超え、更に制限したり拡張したりできます。 こうしたフラグは制約や空の制約に適用できます。 後者は例えば依存関係に不安定なパッケージを許容したい場合などです。

例：

{
    "require": {
        "monolog/monolog": "1.0.*@beta",
        "acme/foo": "@dev"
    }
}

依存関係のうち、不安定なパッケージに依存しているものがあれば、同様に明示的に必要安定性フラグと共に要件に加えなければなりません。

例：

doctrine/doctrine-fixtures-bundleが"doctrine/data-fixtures": "dev-master"を要件としているとすると、根幹のcomposer.jsonの中で以下の2行目を加えてdoctrine/data-fixturesパッケージの開発版リリースを許容する必要があります。

{
    "require": {
        "doctrine/doctrine-fixtures-bundle": "dev-master",
        "doctrine/data-fixtures": "@dev"
    }
}

requireとrequire-devは追加で明示的な参照（つまりコミット）に対応しており、たとえ更新を走らせたとしても、開発版のバージョンが与えられた状態で確実に固定されているようにします。 明示的に開発版を要件にして、参照に#<ref>を付けたときにのみ動作します。 また根幹限定の機能であり、依存関係では無視されます。

例：

{
    "require": {
        "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
        "acme/foo": "1.0.x-dev#abc123"
    }
}

補足： この機能には厳しい技術的制約があり、composer.jsonのメタデータはハッシュの前に指定されたブランチ名から読み込んでしまいます。 したがって、この機能は開発時に一時的に取る解決法とするべきです。 一時的な問題を矯正するための、タグ付けされたリリースに切り替えるまでの対処法なのです。 Composerチームはこの機能に活発に対応しておらずこれに関するバグ報告を受け付けません。

パッケージ制約をインラインエイリアスすることも可能で、そうでなければ合致しない制約に合致させられます。詳細についてはエイリアスの記事を参照してください。

requireとrequire-devはまた、プロジェクトを正常に走らせるために必要な特定のPHPとPHPの拡張のバージョンとへの参照に対応しています。

例：

{
    "require": {
        "php": ">=7.4",
        "ext-mbstring": "*"
    }
}

補足： プロジェクトが要件とするPHP拡張を一覧にすることは重要です。 PHPのインストールが全て同じようになされるとは限りません。 標準と考えている拡張が欠けているものもあるでしょう（例えばext-mysqliは、Fedora/CentOSの最小インストールシステムでは既定ではインストールされません）。 必要なPHPの要件を一覧にし損ねると、利用者体験が悪化することに繋がります。 Composerはパッケージをインストールするときは失敗することなく、実行時に失敗するからです。 composer show --platformコマンドはシステムで利用できる全てのPHP拡張を一覧にします。 これを使えば、使用する拡張の一覧をコンパイルして要件に加える補助になるでしょう。 代えてサードパーティーツールを使ってプロジェクトを解析し、使用されている拡張の一覧が得られるかもしれません。

require

このパッケージが必要とするパッケージの対応付けです。 これらの要件が満たされない限り、パッケージはインストールされません。

require-dev (根幹限定)

このパッケージを開発したり、テストを走らせたりなどするのに必要なパッケージへの対応付けです。 根幹パッケージの開発要件は既定でインストールされます。 installとupdateの両方とも--no-devオプションに対応しており、開発依存関係がインストールされるのを阻止できます。

conflict

このバージョンのパッケージと競合するパッケージへの対応付けです。 それらのパッケージがこのパッケージと共にインストールされるのを許容しないようにします。

なお、conflictリンクで<1.0 >=1.1のような範囲を指定する場合、1.0より小さく且つ同時に1.1かそれより新しい全てのバージョンと競合しているという意味になります。 恐らくやりたいことではないでしょう。 この場合は<1.0 || >=1.1としたいことでしょう。

replace

このパッケージが置き換えるパッケージへの対応付けです。 これによりパッケージをフォークし、独自のバージョン番号を持つ異なる名前で公開できます。 また元のパッケージが置き換わっているため、元のパッケージを要件とするパッケージはフォークしたパッケージを使って動作し続けることになります。

副パッケージを含むパッケージについても有用です。 例えば主眼のsymfony/symfonyパッケージには個々のパッケージとしても使える全てのSymfony Componentが含まれています。 主眼のパッケージを要件にすると、自動的に個々のコンポーネントのうち、どれか1つの要件が充足されます。 主眼のパッケージがコンポーネントを置き換えるからです。

上記で説明した副パッケージの目的で置き換えを使う際は忠告があります。 その場合は通常、self.versionをバージョン制約として使うことで置き換えるだけにしておくべきです。 主眼のパッケージが厳密なバージョンの副パッケージのみを置き換えるようにするためです。 他のバージョンになるとおかしなことになるでしょう。

provide

このパッケージにより提供されるパッケージの対応付けです。 これが最も役立つのは、共通化されたインターフェースの実装です。 パッケージは仮想パッケージに依存できます。 例としてはpsr/log-implementationで、このロガーインターフェースを実装する任意のライブラリはprovideの一覧に加えます。 実装しているパッケージはPackagist.orgで探せます。

仮想的なパッケージではなく、実際のパッケージの名前でprovideを使うことは、そのパッケージのコードも世に出ているということを暗示します。 その場合、一般的にはreplaceがより良い選択です。 インターフェースを提供して実装を提供する他のパッケージに任せる際（例えばPSRのインターフェース）のよくある慣習は、インターフェースパッケージに対応する仮想パッケージの名前に-implementation後置詞を使うことです。

suggest

このパッケージを向上させたりいい感じに動かせたりするようなお勧めのパッケージです。 これらは通知のようなもので、パッケージがインストールされた後に表示されます。 利用者にもっとパッケージを加えてもらえるような手掛かりを与えるためのもので、厳密には必要でなかったとしても大丈夫です。

形式は上述のパッケージリンクと同様ですが、値が自由な内容のテキストで、バージョン制約ではない点は異なります。

例：

{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow",
        "ext-xml": "Needed to support XML format in class Foo"
    }
}

autoload

PHPの自動読み込み器用の自動読み込みの対応付けです。

PSR-4とPSR-0の自動読み込み、classmap生成、filesによる包含に対応しています。

PSR-4はずっと簡単に使えるためお勧めの方法です（クラスを追加したときに自動読み込み器を再生成する必要がありません）。

PSR-4

psr-4キー配下では名前空間からパスへの対応付けを定義します。 パスはパッケージの根幹から相対的なものです。 Foo\\Bar\\Bazのようなクラスを自動読み込みする場合、ディレクトリsrc/を指す名前空間の前部分Foo\\は、自動読み込み器がsrc/Bar/Baz.phpという名前のファイルを探索し、もしあれば含めるという意味です。 なお、比較的古いPSR-0の様式とは反対に、前部分 (Foo\\) はファイルパスに存在しません。

名前空間の前置詞は、似た前置詞との競合を避けるため、\\で終わっていなければなりません。 例えばFooはFooBar名前空間のクラスに照合するので、後ろにバックスラッシュを付けると問題が解決します。 Foo\\とFooBar\\は独立しています。

PSR-4の参照は、installやupdateの際に、単一のキー=>バリュー配列に全て結合されます。生成されるファイルvendor/composer/autoload_psr4.phpで確認できます。

例：

{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

複数のディレクトリで同じ前置詞を検索する必要がある場合は、以下のように配列として指定できます。

{
    "autoload": {
        "psr-4": { "Monolog\\": ["src/", "lib/"] }
    }
}

任意の名前空間が探索されるようなフォールバックディレクトリを持たせたければ、次のように空の前置詞が使えます。

{
    "autoload": {
        "psr-4": { "": "src/" }
    }
}

PSR-0

psr-0キーの配下では名前空間からパスへの対応付けを定義します。 このパスはパッケージの根幹から相対的です。 なお、PEARの様式の名前空間が付いていない変換にも対応しています。

注意していただきたいのは、自動読み込み器が厳密に応答するよう、名前空間の宣言が\\で終わるようにすべきということです。 例えばFooはFooBarに照合してしまうため、後ろにバックスラッシュを付けると問題が解決するでしょう。 Foo\\とFooBar\\は独立しています。

PSR-0の参照はinstallやupdateの際に全て単一のキー=>配列値に束ねられます。 生成されたファイルvendor/composer/autoload_namespaces.phpで確認できます。

例：

{
    "autoload": {
        "psr-0": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
}

複数のディレクトリで同じ前置詞を検索する必要がある場合は、以下のように配列として指定できます。

{
    "autoload": {
        "psr-0": { "Monolog\\": ["src/", "lib/"] }
    }
}

PSR-0の様式は名前空間の宣言のみに留まらず、クラス水準にまで指定できます。 大域的な名前空間で、ただ1つのクラスを持つライブラリについては便利かもしれません。 例えばphpのソースファイルがパッケージの根幹に位置している場合、このように宣言できます。

{
    "autoload": {
        "psr-0": { "UniqueGlobalClass": "" }
    }
}

どの名前空間にもなれるフォールバックディレクトリを持たせたければ、次のような空の前置詞を使うことができます。

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

クラスマップ

classmap参照はinstall/update中に単一のキー=>バリュー配列に全て束ねられ、vendor/composer/autoload_classmap.phpにファイルが生成されます。この対応付けは与えられたディレクトリやファイルにある全ての.phpまたは.incファイル中のクラスを読み取ることによって構築されます。

クラスマップ生成を使ってPSR-4に従わない全てのライブラリ用の自動読み込み器を定義できます。 これを設定するには、クラスを検索する全てのディレクトリないしファイルを指定します。

例：

{
    "autoload": {
        "classmap": ["src/", "lib/", "Something.php"]
    }
}

クラスマップのパスではワイルドカード (*) にも対応しており、任意のディレクトリ名に照合するよう展開されます。

例：

{
    "autoload": {
        "classmap": ["src/addons/*/lib/", "3rd-party/*", "Something.php"]
    }
}

ファイル

必要に応じて特定のファイルを明示的にrequireしたい場合は、files自動読み込み機構を使うことができます。 PHPによって自動読み込みできないPHPの関数を含むパッケージがあるときに便利です。

例：

{
    "autoload": {
        "files": ["src/MyLibrary/functions.php"]
    }
}

filesの自動読み込みの規則はvendor/autoload.phpが含まれたときは常に取り込まれ、ちょうど自動読み込み器が登録された後になります。 取り込み順序はパッケージの依存関係によります。 そのためパッケージAがBに依存している場合、パッケージBにあるファイルが最初に取り込まれます。 パッケージAのファイルが取り込まれた時点でパッケージBが完全に取り込まれて準備ができているようにするためです。

2つのパッケージが同量の依存関係を持つ、あるいは依存関係がない場合、順番は辞書順になります。

根幹パッケージのfilesは常に最後に読み込まれるため、filesを使って依存関係由来の関数を上書きするために自身を自動読み込みさせることはできません。 そうしたい場合はComposerのvendor/autoload.phpを取り込む前に独自の関数を取り込むことをお勧めします。

クラスマップからファイルを除外する

クラスマップから何らかのファイルやディレクトリを除外したければexclude-from-classmapプロパティを使うことができます。 例えば、実環境でテストクラスを除外するのに便利かもしれません。 最適化された自動読み込み器を構築しているときでも、クラスマップから読み飛ばされるからです。

クラスマップ生成器はここで設定されたパスにある全てのファイルを無視します。 パスはパッケージの根幹ディレクトリからの絶対位置にあり、スラッシュ以外の全てに照合する*と任意のものに照合する**に対応しています。 **はパスの末尾に暗黙に追加されます。

例：

{
    "autoload": {
        "exclude-from-classmap": ["/Tests/", "/test/", "/tests/"]
    }
}

自動読み込み器を最適化する

自動読み込み器がリクエスト時間にかなり無視できない影響があることがあります（沢山のクラスを使う大きなフレームワークではリクエストあたり50-100msです）。 この影響を低減する方法についての詳細は自動読み込み器の最適化についての記事を参照してください。

autoload-dev （根幹限定）

この節では開発目的の自動読み込み規則を定義できます。

テストスートを走らせるのに必要なクラスは、主眼のの自動読み込み規則に含めるべきではありません。 実運用や他の人がパッケージを依存関係として使う際に、自動読み込み器を汚染するのを避けるためです。

したがって単体試験専用のパスを用意してautoload-dev節内に追加するのは良いことです。

例：

{
    "autoload": {
        "psr-4": { "MyLibrary\\": "src/" }
    },
    "autoload-dev": {
        "psr-4": { "MyLibrary\\Tests\\": "tests/" }
    }
}

include-path

時代遅れ ： 古びたプロジェクトに対応するためだけに存在し、全ての新しいコードでは自動読み込み器の方を使うべきです。 そうしたわけで時代遅れなものですが、機能自体はComposerから消えることはきっとないでしょう。

PHPのinclude_pathに後付けされるパスのリストです。

例：

{
    "include-path": ["lib/"]
}

省略可能です。

target-dir

時代遅れ ： 古びたPSR-0様式の自動読み込みに対応するためだけに存在しており、全ての新しいコードはtarget-dir無しのPSR-4を使うべきです。 PHPの名前空間と共にPSR-0を使っているプロジェクトは代わりにPSR-4への移行が推奨されます。

インストール対象を定義します。

パッケージの根幹が名前空間宣言の元にある場合は適切に自動読み込みできません。 target-dirはこの問題を解決します。

一例はSymfonyです。これにはコンポーネント毎に独立のパッケージがあります。 YamlコンポーネントはSymfony\Component\Yaml以下にあります。 パッケージの根幹はそのYamlディレクトリです。 自動読み込みできるようにするには、必ずvendor/symfony/yamlではなくvendor/symfony/yaml/Symfony/Component/Yamlにインストールされるようにしなければいけません。 自動読み込み器がvendor/symfony/yamlから読み込めるようにするためです。

そうするために、autoloadとtarget-dirは以下のように定義されています。

{
    "autoload": {
        "psr-0": { "Symfony\\Component\\Yaml\\": "" }
    },
    "target-dir": "Symfony/Component/Yaml"
}

省略可能です。

minimum-stability (根幹限定)

安定性によってパッケージの絞り込みをする既定の挙動を定義します。 この既定はstableになっているので、devのパッケージに依っている場合は、驚くようなことになるのを避けるためにファイルを指定しておくべきです。

各パッケージの全バージョンについて安定性が検査され、minimum-stability設定より安定していないものは、プロジェクトの依存関係の解決の際に無視されます（なお、requireブロック中で指定するバージョン制約中の安定性フラグを使って、パッケージ毎に安定性の要件を指定することもできます（詳細はパッケージリンクを参照））。

使えるオプションは（安定性の順番で）dev、alpha、beta、RC、stableです。

prefer-stable （根幹限定）

これが有効になっているとき、互換性のある安定的なパッケージが使える場合に、不安定なものより安定なパッケージを贔屓します。 開発版が必要だったりパッケージでアルファ版しか使えなかったりする場合については、minimum-stabilityが許容するかどうかが考慮された上で選択されます。

有効にするには"prefer-stable": trueを使ってください。

repositories （根幹限定）

独自に使用するパッケージリポジトリです。

既定ではComposerはpackagistリポジトリのみを使います。 リポジトリを指定することによって、パッケージをどこからでも取得できます。

リポジトリは再帰的に解決されません。 主眼のcomposer.jsonに加えることができるだけです。 依存関係のリポジトリのcomposer.jsonにある宣言は無視されます。

以下のリポジトリの種別に対応しています。

  • composer: Composerリポジトリはネットワーク（HTTP、FTP、SSH）越しに提供されているpackages.jsonであり、追加のdistないしsourceの情報付きのcomposer.jsonのリストを含みます。 packages.jsonファイルはPHPのストリームを使って読み込まれます。 optionsパラメータを使ってストリームについての追加のオプションを設定できます。
  • vcs: パッケージをgit、svn、fossil、hgのリポジトリから取得できるバージョン管理システムリポジトリです。
  • package: 何らのComposer対応がされていないプロジェクトに依存する場合、packageリポジトリを使ってパッケージの定義を書き下すことができます。基本的にcomposer.jsonオブジェクトを書き下します。

これらについての詳細な情報についてはリポジトリを参照してください。

例：

{
    "repositories": [
        {
            "type": "composer",
            "url": "http://packages.example.com"
        },
        {
            "type": "composer",
            "url": "https://packages.example.com",
            "options": {
                "ssl": {
                    "verify_peer": "true"
                }
            }
        },
        {
            "type": "vcs",
            "url": "https://github.com/Seldaek/monolog"
        },
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "https://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "https://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                }
            }
        }
    ]
}

補足： ここでは順番に意味があります。 パッケージを探すとき、Composerは最初から最後までリポジトリを探し、最初に照合したものを拾います。 既定ではPackagistが最後に加えられており、つまり独自のリポジトリがPackagistのパッケージより優先されるのです。

JSONオブジェクト記法を使うこともできます。 しかしJSONのキーバリュー対は順序なしとして見做されるため、一貫した挙動は保証されません。

{
    "repositories": {
        "foo": {
            "type": "composer",
            "url": "http://packages.foo.com"
        }
    }
}

config （根幹限定）

設定オプションの集合です。プロジェクト限定で使われます。それぞれのオプションについての説明については設定を参照してください。

scripts （根幹限定）

Composerではスクリプトの使用を通じてインストールの過程の様々な部分でフックを掛けることができます。

イベントについての詳細と例についてはスクリプトを参照してください。

extra

scriptsによって消費される任意の追加データです。

理論上何でも構いません。 スクリプトのイベント制御子中でアクセスするには以下のようにします。

$extra = $event->getComposer()->getPackage()->getExtra();

省略可能です。

bin

バイナリとして扱われるべきファイルの集合で、（設定の）bin-dirで使えるようにします。

詳細はベンダーバイナリを参照してください。

省略可能です。

archive

パッケージアーカイブをつくるためのオプションの集合です。

以下のオプションに対応しています。

  • name: アーカイブの基底名を設定できます。既定（設定されていない場合で、かつコマンドライン引数として--fileが渡されていない場合）ではpreg_replace('#[^a-z0-9-_]#i', '-', name)が使われます。

例：

{
    "name": "org/strangeName",
    "archive": {
        "name": "Strange_name"
    }
}
  • exclude: 除外されるパス用のパターンのリストを設定できます。 パターンの構文は.gitignoreファイルのものと同一です。 先頭のびっくりマーク (!) はそれ以前のパターンが除外していたとしても照合したファイルを含めることになります。 先頭のスラッシュはプロジェクトの相対パスの開始部分にのみ照合します。 アスタリスクはディレクトリの区切りに展開されません。

例：

{
    "archive": {
        "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"]
    }
}

例では/dir/foo/bar/file、/foo/bar/baz、/file.php、/foo/my.testを含みますが、/foo/bar/any、/foo/baz、/my.testは除外します。

省略可能です。

abandoned

このパッケージが放棄されたものかどうかを示します。

真偽値または推奨される代替を指すパッケージ名やURLです。

例：

"abandoned": trueを使うと、このパッケージが放棄されたことを示します。 "abandoned": "monolog/monolog"を使うと、このパッケージが放棄され、推奨される代替がmonolog/monologであることが示されます。

既定では偽です。

省略可能です。

_comment

コメントを入れておく場所として使える最上位のキーです（文字列または文字列の配列にできます）。

{
    "_comment": [
        "パッケージfoo/barはビジネスロジックに必要でした",
        "foo/barを削除するときはfoo/bazパッケージを削除してください"
    ]
}

既定では空です。

省略可能です。

non-feature-branches

数値でないブランチ名の正規表現パターン（例：「latest」など）のリストです。 機能用ブランチを決して扱いません。 文字列の配列です。

数値でないブランチ名がある場合、例えば「latest」「current」「latest-stable」などについては、バージョン番号には見えないので、Composerはそうしたブランチを機能用ブランチとして制御します。 つまりバージョンや特別なブランチ（masterなど）で終わっているような親ブランチを探し、根幹パッケージのバージョン数が親ブランチのバージョンまたは少なくともmasterなどになるということです。

数値でない名前のブランチを、妥当なバージョンやmasterのような特別なブランチ名の親ブランチを探す代わりに、バージョンとして扱うようにするには、開発版ブランチとして制御されるべきブランチ名のパターンを設定できます。

「self.version」を使う依存関係があるときは本当に便利です。 このときdev-masterでなくとも同じブランチがインストールされます（例：latest-testing）。

一例：

テストブランチがある場合で、そのブランチがテストフェーズで手厚く維持管理され、ステージング環境にデプロイされるのであれば、通常composer show -sとするとversions : * dev-masterになります。

機能用ブランチではないもの用にlatest-.*をパターンとして設定する場合はこのようにします。

{
    "non-feature-branches": ["latest-.*"]
}

それからcomposer show -sとするとversions : * dev-latest-testingになります。

省略可能です。

← コマンドラインインターフェース | リポジトリ →

リポジトリ

この章ではパッケージとリポジトリの概念、利用できるリポジトリの種類に何があるか、そしてどういう仕組みになっているのかを解説します。

概念

リポジトリのそれぞれの存在する種別を見ていく前に、Composerが立脚する基礎概念を理解する必要があります。

パッケージ

Composerは依存関係管理ツールです。 パッケージをローカルにインストールします。 パッケージは本質的には何かを含むディレクトリです。 この場合はその何かがPHPのコードですが、理論上何でも良いわけです。 そしてパッケージの名前とバージョンを持つパッケージの説明を含みます。 名前とバージョンはパッケージを特定するのに使われます。

実際、内部的にはComposerはそれぞれのバージョンを個別のパッケージとして見做します。 この区別はComposerを使っているときは問題になりませんが、Composer自体を変更したいと思ったときはかなり重要になります。

名前とバージョンに加えて有用なメタデータがあります。 インストールに最も関係する情報はソースの定義で、どこかでパッケージの内容を取得するのかを記述します。 パッケージのデータはパッケージの内容を指します。 そしてここで2つの選択肢があります。 distとsourceです。

dist: distはパッケージデータのパッケージ化されたバージョンです。大抵はリリースバージョンで、中でも大抵は安定リリースです。

source: ソースは開発に使われます。 大抵gitのようなソースコードリポジトリを起源とします。 ダウンロードされたパッケージを変更したいときはこれを取得できます。

パッケージはこれらの何れか、または両方を与えられます。 利用者により与えられたオプションやパッケージの安定性などの何らかの要因により、どちらかが相応ということになるでしょう。

リポジトリ

リポジトリはパッケージソースで、パッケージとバージョンのリストです。 Composerは全てのリポジトリを見て回り、プロジェクトに必要なパッケージを見付けてきます。

既定ではPackagist.orgリポジトリがComposerに登録されています。composer.jsonに宣言することでプロジェクトにもっとリポジトリを加えることができます。

リポジトリは根幹パッケージでのみ利用でき、依存関係で定義されたリポジトリは読み込まれません。 なぜそうなっているかを知りたければFAQの項目をお読みください。

依存関係解決をするとき、パッケージはリポジトリを上から下への順で見ていき、どこかにパッケージがあったらComposerは他のリポジトリを見るのを止めます。 詳細はリポジトリの優先度の記事を読んで、この挙動を変える方法を見てください。

種別

composer

主なリポジトリの種別はcomposerリポジトリです。全てのパッケージメタデータを含む単一のpackages.jsonファイルを使っています。

packagistが使っているリポジトリの種別でもあります。 composerリポジトリを参照するには、packages.jsonファイルの前にパスを与えてください。 packagistの場合、そのファイルは/packages.jsonに配置されるので、リポジトリのURLはrepo.packagist.orgとなります。 example.org/packages.jsonについてはリポジトリのURLはexample.orgになります。

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://example.org"
        }
    ]
}

packages

唯一必要なフィールドはpackagesです。JSONの構造は以下のようなものです。

{
    "packages": {
        "vendor/package-name": {
            "dev-master": { @composer.json },
            "1.0.x-dev": { @composer.json },
            "0.0.1": { @composer.json },
            "1.0.0": { @composer.json }
        }
    }
}

@composer.jsonの印は、最小のものとして含むパッケージのバージョンに由来するcomposer.jsonの内容になります。

  • name
  • version
  • distまたはsource

以下は最小限のパッケージの定義です。

{
    "name": "smarty/smarty",
    "version": "3.1.7",
    "dist": {
        "url": "https://www.smarty.net/files/Smarty-3.1.7.zip",
        "type": "zip"
    }
}

スキーマには指定される他のフィールドの何れかを含められます。

notify-batch

notify-batchフィールドでは利用者がパッケージをインストールするときに毎回呼ばれるURLを指定できます。 URLは絶対パス（リポジトリと同じドメイン）ないし完全に修飾されたURLです。

値の一例：

{
    "notify-batch": "/downloads/"
}

monolog/monologパッケージを含むexample.org/packages.jsonについて、このようにすると以下のJSON要求本文とともにexample.org/downloads/へPOST要求を送ります。

{
    "downloads": [
        {"name": "monolog/monolog", "version": "1.2.1.0"}
    ]
}

バージョンフィールドはバージョン数の正規化された表現を含みます。

このフィールドは省略できます。

metadata-url、available-packages、available-package-patterns

metadata-urlフィールドでは、リポジトリにある全てのパッケージを提供するURLテンプレートを与えます。 プレースホルダー%package%を含まなければなりません。

このフィールドはComposer v2で新しく登場したもので、provider-includesとproviders-urlが両方とも存在する場合、これらより優先されます。 Composer v1とComposer v2両方の互換性のため、理想的には両方とも提供したいでしょう。 しかし新しいリポジトリの実装はv2対応のみに対応しさえすれば良いです。

一例：

{
    "metadata-url": "/p2/%package%.json"
}

Composerがパッケージを探すときは毎回%package%をパッケージ名で置き換え、そのURLを取得します。開発安定性がそのパッケージについて許容される場合、$packageName~devで再びURLを読み込むことができます（例：/p2/foo/bar~dev.jsonはfoo/barの開発版を探します）。

パッケージのバージョンを含むfoo/bar.jsonとfoo/bar~dev.jsonファイルはfoo/barパッケージのバージョンのみを含まなければなりません。{"packages":{"foo/bar":[……ここにバージョン……]}}のような感じです。

キャッシュはIf-Modified-Sinceヘッダを使うことで行われます。ですから必ずLast-Modifiedヘッダを返して正確な内容であるようにしてください。

バージョンの配列はcomposer/metadata-minifierのComposer\MetadataMinifier\MetadataMinifier::minify()を使って最小化することもできます。 もしそうした場合、最上位に"minified": "composer/2.0"キーを付け、Composerにバージョンのリストを展開して元のデータに戻さなければいけないことを示すべきです。 一例として https://repo.packagist.org/p2/monolog/monolog.json を参照してください。

存在しないパッケージを要求されたら404ステータスコードを返さなければなりません。このステータスコードによりComposerにこのパッケージがリポジトリに存在しないことが示されます。404応答は早く返してComposerがブロックされるのを回避するようにしてください。代替の404ページへのリダイレクトは避けてください。

リポジトリにごく少数のパッケージしかなく、404になる要求を避けたければpackages.jsonにリポジトリに含まれる全てのパッケージ名が配列になった"available-packages"キーを指定することもできます。代わりにパッケージ名のパターンの配列である"available-package-patterns"キーを指定することもできます（*だと任意の文字列に照合します。例：vendor/*ではComposerはこのリポジトリにある全ての照合したパッケージ名を探します）。

このフィールドは省略できます。

providers-api

providers-apiフィールドでは、与えられたパッケージ名を提供する全てのパッケージをサーバーから返すURLの雛形を与えられます。 ただし、その名前を持つパッケージが存在したとしても、そのパッケージは含まれません。 プレースホルダー%package%を含まなければなりません。

例えば https://packagist.org/providers/monolog/monolog.json は、psr/log-implementationに「provide」規則があるパッケージを一覧にします。

{
    "providers-api": "https://packagist.org/providers/%package%.json",
}

このフィールドは省略できます。

list

listフィールドでは与えられたフィールド（もしくはフィルタが存在しなければ全ての名前）に照合するパッケージの名前を返せます。 任意で?filter=xxクエリパラメータを受け付けますが、これには任意の部分文字列に照合するワイルドカードとして*を含められます。

replace/provide規則はここでは考慮すべきではありません。

パッケージ名の配列を返さねばなりません。

{
    "packageNames": [
        "a/b",
        "c/d"
    ]
}

例についてはhttps://packagist.org/packages/list.json?filter=composer/*を参照してください。

このフィールドは省略できます。

provider-includesとproviders-url

provider-includesフィールドでは、このリポジトリから提供されるパッケージ名を一覧にするファイルの集まりを列挙できます。 この場合ハッシュはファイルのsha256になります。

providers-urlは提供するファイルをサーバーで見付ける方法を記述します。 リポジトリの根幹からの絶対パスです。 %package%と%hash%のプレースホルダーを含まなければいけません。

これらのフィールドは、Composer v1かリポジトリがmetadata-urlフィールドを設定していない場合に使われます。

一例：

{
    "provider-includes": {
        "providers-a.json": {
            "sha256": "f5b4bc0b354108ef08614e569c1ed01a2782e67641744864a74e788982886f4c"
        },
        "providers-b.json": {
            "sha256": "b38372163fac0573053536f5b8ef11b86f804ea8b016d239e706191203f6efac"
        }
    },
    "providers-url": "/p/%package%$%hash%.json"
}

これらのファイルにはファイルの完全性を検証するハッシュが含まれます。例えば次の通りです。

{
    "providers": {
        "acme/foo": {
            "sha256": "38968de1305c2e17f4de33aea164515bc787c42c7e2d6e25948539a14268bb82"
        },
        "acme/bar": {
            "sha256": "4dd24c930bd6e1103251306d6336ac813b563a220d9ca14f4743c032fb047233"
        }
    }
}

上のファイルはproviders-urlで参照されたファイルを読み込むことにより、このリポジトリにacme/fooとacme/barがあることを宣言しています。 ベンダーの名前空間が付いたパッケージ名で%package%を、%hash%をsha256フィールドを、それぞれ置き換えます。 これらのファイル自体には上で前述したパッケージの定義が含まれます。

これらのフィールドは省略可能です。 恐らく独自のリポジトリでは必要ないでしょう。

cURLとストリームオプション

リポジトリへはcURL（ext-curlが有効なComposer 2）またはPHPストリームの何れかを使ってアクセスします。 optionsパラメータを使って追加のオプションを設定できます。 PHPストリームについては、任意の妥当なPHPストリームコンテキストオプションを設定できます。 詳細はコンテキストオプションとパラメータを参照してください。 cURLが使われているとき、ごく一部のhttpとsslオプションしか設定できないように制限されます。

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://example.org",
            "options": {
                "http": {
                    "timeout": 60
                }
            }
        }
    ],
    "require": {
        "acme/package": "^1.0"
    }
}

VCS

VCSはバージョンコントロールシステム (Version Control System) から来ています。これにはgit、svn、fossil、hgのようなバージョニングシステムが含まれます。Composerにはこれらのシステムからパッケージをインストールするリポジトリ種別があります。

VCSリポジトリからパッケージを読み込む

これにはいくつかの使い途があります。 一番よくあるものとしては、サードパーティライブラリの独自のフォークを維持管理することです。 プロジェクトで或るライブラリを使用していて、ライブラリ内の何かを変更し、プロジェクトでパッチを適用したバージョンを使用しようと思ったとします。 ライブラリがGitHubにある場合（殆どのライブラリが当てはまります）、フォークして、変更をフォークにプッシュできます。 その後、プロジェクトのcomposer.jsonを更新します。 する必要があるのは、フォークをリポジトリとして追加し、バージョン制約を更新してカスタム ブランチを指すようにすることだけです。 composer.json でのみ、カスタムブランチ名の前に"dev-"を付けるべきです（実際のブランチ名の一部にしないでください）。 バージョン制約の命名規則については、ライブラリを参照してください。

bugfixブランチのバグを修正するためにmonologにパッチを当てたときの例は以下です。

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/igorw/monolog"
        }
    ],
    "require": {
        "monolog/monolog": "dev-bugfix"
    }
}

php composer.phar updateを実行すると、修正したバージョンのmonolog/monologが取得されます。packagistからのものではありません。

長期的にフォークするつもりがない限り、パッケージを改名しないでください。 また、もし変更するならするで、元のパッケージから完全に離れたものにする必要があります。 独自リポジトリはpackagistよりも優先されるため、Composerは元のパッケージではなく自前のパッケージを正しく選択します。 パッケージを改名する場合、パッケージ名が既定のブランチから取得されるため、機能ブランチではなく、既定の（多くの場合master）ブランチで行う必要があります。

また、フォークされたリポジトリのcomposer.jsonファイルのnameプロパティを変更すると、上書きが機能しないことに注意してください。 上書きが機能するには元のものと合致する必要があるからです。

他の依存関係がフォークしたパッケージに依存している場合は、それをインラインエイリアスして、他の方法では一致しない制約に一致させることができます。 詳細についてはエイリアスの記事を参照してください。

私有リポジトリを使う

GitHubとBitbucketの私有リポジトリを全く同じやり方で扱えます。

{
    "repositories": [
        {
            "type": "vcs",
            "url":  "git@bitbucket.org:vendor/my-private-repo.git"
        }
    ],
    "require": {
        "vendor/my-private-repo": "dev-master"
    }
}

唯一の要件は、gitクライアント用のSSHキーがインストールされていることです。

Gitの代替案

VCSリポジトリで対応しているバージョン管理システムはGitだけではありません。 以下に対応しています。

これらのシステムからパッケージを取得するにはそれぞれのクライアントがインストールされてる必要がありますが、これだと不便かもしれません。 このため、GitHubとBitbucketについては、これらのサイトが提供するAPIを使用して、バージョン管理システムをインストールせずにパッケージを取得する特別な対応が入っています。 VCSリポジトリは、パッケージをzipとして取得するdistを提供します。

使用するVCSドライバーは、URLに基づいて自動的に検出されます。 ただし、何らかの理由で指定する必要がある場合は、vcsに代えてbitbucket、github、gitlab、perforce、fossil、git、svn、hgがリポジトリの種類として使えます。

githubリポジトリでno-apiキーをtrueに設定すると、GitHub APIは使用せず、他のgitリポジトリと同様にリポジトリがクローンされます。 ただし、gitドライバーを直接使用する場合とは異なり、Composerは依然としてgithubのzipファイルを使用しようとします。

以下の点に注意してください。

  • Composerに使用するドライバを選ばせるには、リポジトリの種類は「vcs」として定義されている必要があります
  • 既に私有リポジトリを使っている場合、Composerはキャッシュへクローンすることになります。 同じパッケージをドライバと一緒にインストールしたい場合、composer clearcacheコマンドに続けてcomposer updateとすることでComposerのキャッシュを消去しdistからパッケージをインストールさせられることを覚えておきましょう
  • VCSドライバgit-bitbucketはbitbucketに取って代わられたため時代遅れです

Bitbucketドライバ設定

Bitbucketのリポジトリのエンドポイントはgitではなくhttpsになっている必要がある点に注意してください。

bitbucketリポジトリが準備できたら認証の準備もする必要があるでしょう。

Subversionのオプション

Subversion自体にはブランチとタグの概念がないため、Composerは既定でコードが$url/trunk、$url/branches、$url/tagsにあるという前提を置きます。 リポジトリの配置が異なる場合は、それらの値を変更できます。 たとえば、大文字の名前を使用した場合、次のようにリポジトリを構成できます。

{
    "repositories": [
        {
            "type": "vcs",
            "url": "http://svn.example.org/projectA/",
            "trunk-path": "Trunk",
            "branches-path": "Branches",
            "tags-path": "Tags"
        }
    ]
}

ブランチのディレクトリもタグのディレクトリもなければbranches-pathないしtags-pathをfalseに設定することで完全に無効にできます。

パッケージが副ディレクトリにある、例えば/trunk/foo/bar/composer.jsonと/tags/1.0/foo/bar/composer.jsonにあるなら、"package-path"オプションを副ディレクトリに設定することでComposerがアクセスできるようにさせられます。 この例では"package-path": "foo/bar/"となるでしょう。

私有Subversionリポジトリがあるなら設定のhttp-basic節に資格情報を保存しておけます（スキーマを参照）。

{
    "http-basic": {
        "svn.example.org": {
            "username": "username",
            "password": "password"
        }
    }
}

Subversionクライアントが既定で資格情報を保存するように構成されている場合、これらの資格情報は現在の利用者用に保存され、このサーバー用に保存されている既存の資格情報は上書きされます。 この挙動を変更するには、次のようにリポジトリ構成で"svn-cache-credentials"オプションを設定します。

{
    "repositories": [
        {
            "type": "vcs",
            "url": "http://svn.example.org/projectA/",
            "svn-cache-credentials": false
        }
    ]
}

パッケージ

上記のどの方法でもComposerに対応していないプロジェクトを使いたい場合でも、packageリポジトリを使って自分でパッケージを定義できます。

基本的にcomposerリポジトリのpackage.jsonに含まれるのと同じ情報を定義しますが、単一のパッケージ用限定です。 繰り返しますが、最小限必要なフィールドはname、version、そしてdistまたはsourceの何れかです。

以下は雛形エンジンのsmartyの例です。

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "smarty/smarty",
                "version": "3.1.7",
                "dist": {
                    "url": "https://www.smarty.net/files/Smarty-3.1.7.zip",
                    "type": "zip"
                },
                "source": {
                    "url": "http://smarty-php.googlecode.com/svn/",
                    "type": "svn",
                    "reference": "tags/Smarty_3_1_7/distribution/"
                },
                "autoload": {
                    "classmap": ["libs/"]
                }
            }
        }
    ],
    "require": {
        "smarty/smarty": "3.1.*"
    }
}

source部分は放置しておくのが普通です。本当に必要なことはまずないからです。

sourceキーが含まれているとき、referenceフィールドはインストールされるバージョンへの参照となります。 typeフィールドがgitのとき、このフィールドはコミットIDやブランチやタグ名になります。

補足： referenceフィールドにGitのブランチ名を使うことはお勧めしません。 git checkoutに対応しているため妥当ではあるのですが、ブランチ名は可変なので固定できないのです。

フィールドがsvnのとき、referenceフィールドにはsvn coを走らせるときに後ろに付ける参照が含まれます。

補足： このリポジトリ種別には2、3の制約があり、できる限り避けるべきです。

  • Composerはversionフィールドを変えない限りパッケージを更新しません。
  • Composerはコミット参照を更新しません。 そのため、参照としてmasterを使う場合、強制的に更新するためにパッケージを削除し、不安定な固定ファイルに対処しなければならなくなるでしょう。

packageリポジトリ中の"package"キーには複数バージョンのパッケージを定義する配列を設定できます。

{
    "repositories": [
        {
            "type": "package",
            "package": [
                {
                    "name": "foo/bar",
                    "version": "1.0.0",
                    ...
                },
                {
                    "name": "foo/bar",
                    "version": "2.0.0",
                    ...
                }
            ]
        }
    ]
}

自分でホスティングする

多分殆どの場合でパッケージをpackagistに置きたいものと思われますが、自分のリポジトリをホスティングすることによる用途もあります。

  • 企業の私有パッケージ： 内部的なパッケージ用にComposerを使っている企業に所属しているなら、それらのパッケージを私有としておきたいかもしれません。

  • 別のエコシステム: 独自のエコシステムを持つプロジェクトがあり、より大きなPHPコミュニティからそのパッケージを実際に再利用できない場合は、packagistから分離させておきたいかもしれません。 一例はWordPressプラグインです。

自分のパッケージをホスティングするには、ネイティブなcomposerの種類のリポジトリが推奨されます。 一番の効率性が齎されるからです。

composerリポジトリを作る上で、手助けになるツールはいくつかあります。

私有Packagist

私有PackagistではGitHub、Packagist.org、その他のパッケージリポジトリのミラーリングと共に私有パッケージのホスティングを提供するアプリケーションです。 Packagistでも立てられていますが、自分で立てることもできます。

詳細はPackagist.comをご確認ください。

Satis

Satisは静的なcomposerリポジトリ生成器です。 packagistを超軽量にして、静的なファイルを基盤にしたバージョンのようなものです。

Satisにはリポジトリを含むcomposer.jsonを与えます。 リポジトリとしてよくあるのはVCSやパッケージレポジトリの定義です。 requireされるパッケージを全て取得し、packages.jsonを吐き出しますが、これがcomposerリポジトリになります。

詳細はsatisのGitHubリポジトリとプライベートパッケージを扱うことについての記事をご確認ください。

アーティファクト

前述のどのリポジトリの種類もオンラインにできない場合があります。 VCSが使われていたとしても例外ではありません。 よくある例は、ビルドアーティファクトによる組織間のライブラリ交換です。 もちろん殆どの場合で、これらは私有とされます。 これらのアーカイブをそのまま使用するには、これらの私有パッケージのZIPまたはTARアーカイブを含むフォルダーに対して、種別artifactのリポジトリを使用できます。

{
    "repositories": [
        {
            "type": "artifact",
            "url": "path/to/directory/with/zips/"
        }
    ],
    "require": {
        "private-vendor-one/core": "15.6.2",
        "private-vendor-two/connectivity": "*",
        "acme-corp/parser": "10.3.5"
    }
}

それぞれのzipアーティファクトとは、根幹のフォルダにあるcomposer.jsonがあるZIPアーカイブです。

unzip -l acme-corp-parser-10.3.5.zip

composer.json
...

パッケージのバージョンが異なる2つのアーカイブがある場合、両方ともインポートされます。 新しいバージョンのアーカイブがアーティファクトフォルダーに追加された状態でupdateを実行すると、そのバージョンもインポートされ、Composerは最新版に更新されます。

パス

アーティファクトリポジトリに加えて、絶対パスまたは相対パスのローカルディレクトリに依存するパスを使用できます。 モノリシックリポジトリを扱う場合に特に役立ちます。

例えばリポジトリが以下のディレクトリ構造になっているとします。

...
├── apps
│   └── my-app
│       └── composer.json
├── packages
│   └── my-package
│       └── composer.json
...

そうして依存関係としてapps/my-app/composer.jsonファイルにパッケージmy/packageを加えるには、以下の構成が使えます。

{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/my-package"
        }
    ],
    "require": {
        "my/package": "*"
    }
}

パッケージがローカルのVCSリポジトリである場合、バージョンは現在チェックアウトされているブランチまたはタグによって推測されます。 それ以外の場合は、パッケージのcomposer.jsonファイルでバージョンを明示的に定義すべきです。 これらの方法でバージョンが解決できない場合は、dev-masterと見なされます。

バージョンがローカルのVCSリポジトリから推測できない場合、もしくはそのバージョンを上書きしたい場合は、リポジトリの宣言時にversionsオプションが使えます。

{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/my-package",
            "options": {
                "versions": {
                    "my/package": "4.2-dev"
                }
            }
        }
    ]
}

可能なときはローカルパッケージがシンボリックリンクされます。 この場合端末の出力はSymlinking from ../../packages/my-packageとなります。 シンボリックリンクできない場合はパッケージが複製されます。 その場合端末の出力はMirrored from ../../packages/my-packageとなります。

既定のフォールバック戦略に代えて、"symlink": trueとしてシンボリックリンクにしたり、"symlink": falseオプションでミラーリングしたりすることを強制できます。 ミラーリングを強制すると、モノリシックレポジトリからパッケージをデプロイしたり生成したりする際に便利なことがあります。

補足： Windowsでは管理者でない利用者によって作成される可能性があるため、NTFSジャンクションを使ってディレクトリのシンボリックリンクが実装されています。 Windows 7より前のバージョンまたはproc_openが無効にされている場合は常にミラーリングが使用されます。

{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/*",
            "options": {
                "symlink": false
            }
        }
    ]
}

チルダを先頭に付けると現在の利用者のホームフォルダに展開され、環境変数はWIndowsとLinux/Macの両方の記法で解析されます。 例えば~/git/mypackageは自動的に/home/<利用者名>/git/mypackageからクローンしたmypackageを読み込みます。 $HOME/git/mypackageとしたり%USERPROFILE%/git/mypackageとしても同じことです。

補足： リポジトリのパスは*や?のようなワイルドカードも含められます。 詳細についてはPHPのglob関数を参照してください。

（composer.lockファイルに現れる）パッケージのdistへの参照が構築される方法を構成できます。

以下のモードが存在します。

  • none：参照は常に空です。 これにより固定ファイル間の競合を低減する助けになる可能性がありますが、直近に更新があるとパッケージが最新の状態になっているかが比較的不明瞭になります。
  • config：参照はパッケージのcomposer.jsonとリポジトリの設定のハッシュに基づいて構築されます
  • auto（既定で使用されます）：参照はcomfigのようなハッシュに基づいて構築されます。 ただしパッケージフォルダがgitリポジトリを含んでいる場合、代わりにHEADコミットのハッシュが参照として使われます。
{
    "repositories": [
        {
            "type": "path",
            "url": "../../packages/*",
            "options": {
                "reference": "config"
            }
        }
    ]
}

Packagist.orgを無効にする

以下をcomposer.jsonに加えると既定のPackagist.orgリポジトリを無効にできます。

{
    "repositories": [
        {
            "packagist.org": false
        }
    ]
}

大域的な構成フラグを使うことで、大域的にPackagist.orgを無効にできます。

php composer.phar config -g repo.packagist.org false

← スキーマ | 設定 →

構成

本章ではcomposer.jsonのスキーマのconfig節について記述していきます。

process-timeout

プロセス実行の制限時間で、秒単位です。 既定では300（5分）です。 git cloneのような時間の掛かるプロセスは、Composerによりプロセスの異常終了が推定されるまで、実行できます。 接続が遅い場合やベンダーが大きい場合は、これを増やす必要があるかもしれません。

例：

{
    "config": {
        "process-timeout": 900
    }
}

個々のスクリプトのコマンドで制限時間を無効にする

scripts以下の独自コマンドでプロセスの制限時間を無効にするには、静的ヘルパーが使えます。

{
    "scripts": {
        "test": [
            "Composer\\Config::disableProcessTimeout",
            "phpunit"
        ]
    }
}

allow-plugins

既定は{}で、1つもプラグインを読み込むことはできません。

Composer 2.2.0では、allow-pluginsオプションによってセキュリティの層が追加され、Composerの実行中にどのComposerプラグインがコードを実行できるかを制限できるようになりました。

新しいプラグインが最初に活性化され、それが構成オプションにまだ挙げられていなければ、Composerは警告を印字します。 Composerを対話的に実行すると、プラグインを実行するかどうかを決めるようプロンプトを出します。

この設定を使うと、信頼できるパッケージのみがコードを実行できるようになります。 パッケージ名パターンをキーに持つオブジェクトに設定します。 値は、許可する場合はtrueで、許可しない場合はfalseです。 何れもこれ以外の警告とプロンプトは抑制されます。

{
    "config": {
        "allow-plugins": {
            "third-party/required-plugin": true,
            "my-organization/*": true,
            "unnecessary/plugin": false
        }
    }
}

構成オプション自体をfalseにして全てのプラグインを拒否したり、trueにして全てのプロラグインが走るのを許可したり（全くお勧めしません）するようにも設定できます。 例えば以下の通りです。

{
    "config": {
        "allow-plugins": false
    }
}

use-include-path

既定ではfalseです。 trueにすると、Composerの自動読み込み器はPHPのインクルードパスにあるクラスも探します。

preferred-install

既定ではdistで、source、dist、autoの何れかです。 このオプションではComposerが優先して使うインストール方法を設定できます。 お好みで、より柔軟なインストール設定のためにキーにパッケージ名のパターンがあるオブジェクトにすることもできます。

{
    "config": {
        "preferred-install": {
            "my-organization/stable-package": "dist",
            "my-organization/*": "source",
            "partner-organization/*": "auto",
            "*": "dist"
        }
    }
}
  • sourceは、Composerが（存在する場合）sourceからパッケージをインストールすることを意味します。 通常、git cloneまたは同等のパッケージが使用するバージョン管理システムのチェックアウトです。 プロジェクトにバグ修正を行い、依存関係のローカルgitクローンを直接取得する場合に便利です。
  • autoは遺物的な動作です。 開発バージョンの場合にComposerはsourceを自動的に使用し、それ以外の場合はdistを使用します。
  • dist（Composer 2.1以降で既定）は、可能であればComposerがdistからインストールすることを意味します。 通常、zipファイルのダウンロードであり、リポジトリ全体のクローンよりも高速です。

補足： 順番は重要です。 より限定されたパターンは、より緩いパターンの前に来るべきです。 大域構成やパッケージ構成で文字列表記とハッシュ構成を混在させると、文字列表記は*パッケージパターンに解釈されます。

audit

セキュリティ監査の構成オプション

ignore

勧告の識別子、リモートの識別子、CVEの識別子のリストです。 報告はされますが監査コマンドは通過させます。

{
    "config": {
        "audit": {
            "ignore": {
                "CVE-1234": "The affected component is not in use.",
                "GHSA-xx": "The security fix was applied as a patch.",
                "PKSA-yy": "Due to mitigations in place the update can be delayed."
            }
        }
    }
}

もしくは以下です。

{
    "config": {
        "audit": {
            "ignore": ["CVE-1234", "GHSA-xx", "PKSA-yy"]
        }
    }
}

abandoned

Composer 2.6ではreportが既定値であり、Composer 2.7以降ではfailが既定値です。 監査コマンドが放棄されたパッケージを報告するかどうかを定義するもので、3つの値を取り得ます。

  • ignoreは、監査コマンドが放棄されたパッケージを全く考慮しないという意味です。
  • reportは、放棄されたパッケージが失敗として報告されるものの、非ゼロコードでコマンドが終了してしまわないようにする意味です。
  • failは、放棄されたパッケージにより監査が非ゼロコードで失敗するようになる意味です。
{
    "config": {
        "audit": {
            "abandoned": "report"
        }
    }
}

Composer 2.7以降、COMPOSER_AUDIT_ABANDONED環境変数を介して、オプションをオーバーライドできます。

Composer 2.8以降、--abandonedコマンドラインオプションを介して、オプションをオーバーライドできます。 このオプションにより、構成値と環境変数が共にオーバーライドされます。

use-parent-dir

composer.jsonがないディレクトリでComposerを実行しており、その上のディレクトリにcomposer.jsonがある場合、Composerは既定で、そのディレクトリのcomposer.jsonを代わりに使用するかどうかを尋ねます。

このプロンプトに対して常に「はい」と答えたい場合は、この構成値をtrueに設定できます。 プロンプトが表示されないようにするには、falseに設定します。 既定は"prompt"です。

補足： この構成を機能させるには、大域的な利用者全体の構成で設定しなければなりません。 例えばphp composer.phar config --global use-parent-dir trueを使用して設定します。

store-auths

認証のプロンプトの後にする動作です。 true（常に保存する）、false（保存しない）、"prompt"（毎回確認する）の何れか1つで、既定では"prompt"です。

github-protocols

既定では["https", "ssh", "git"]です。 github.comからクローンを作成するときに使用するプロトコルのリストで、優先度順に並べます。 既定ではgitが存在しますが、gitプロトコルは暗号化されていないため、secure-httpが無効になっている場合のみ使われます。 originのリモートプッシュURLでssh (git@github.com:...) ではなくhttpsを使用する場合、プロトコルリストを["https"]のみに設定すると、ComposerはプッシュURLをSSHのURLに上書きすることを取り止めます。

github-oauth

ドメイン名とoauthキーのリストです。 たとえば、このオプションの値として{"github.com": "oauthtoken"}を使用すると、oauthtokenを使用してgithubの私有リポジトリにアクセスし、APIのIPに基づく低いレート制限を回避します。 Composerは、必要に応じて資格情報を要求する場合がありますが、これらは手動で設定することもできます。 GitHubのOAuthトークンを取得する方法及びcliの構文の詳細については、こちらを参照してください。

gitlab-domains

既定では["gitlab.com"]です。 GitLabサーバーのドメインのリストです。 gitlabリポジトリ種別を使う場合に使用されます。

gitlab-oauth

ドメイン名とoauthキーのリストです。 たとえば、このオプションの値として{"gitlab.com": "oauthtoken"}を使用すると、oauthtokenを使用してgitlabの私有リポジトリにアクセスします。 なお、パッケージがgitlab.comでホストされていない場合、ドメイン名もgitlab-domainsオプションで指定する必要があります。 詳細情報はこちらにもあります。

gitlab-token

ドメイン名と私有トークンのリストです。 私有トークンは、単純な文字列、または利用者名とトークンを含む配列の何れかです。 たとえば、このオプションの値として{"gitlab.com": "privatetoken"}を使用すると、privatetokenを使用してgitlabの私有リポジトリにアクセスします。 {"gitlab.com": {"username": "gitlabuser", "token": "privatetoken"}}を使用すると、利用者名とトークンの両方を使ってgitlabのデプロイトークン機能 (https://docs.gitlab.com/ ee/user/project/deploy_tokens/) を使用します。 なお、パッケージがgitlab.comでホストされていない場合、ドメイン名もgitlab-domainsオプションで指定する必要があります。 トークンにはapiまたはread_apiスコープが必要です。 詳細情報はこちらにもあります。

gitlab-protocol

パッケージメタデータのsource値用にリポジトリのURLを作成するときに、強制的に使用するプロトコルです。 gitまたはhttpの何れかです（httpsはhttpの同義語として扱われます）。 HTTPベーシック認証を使ったGitLabのCI_JOB_TOKENにより、後々GitLab CIのジョブでクローンされる私有リポジトリを参照するプロジェクトを扱う際に役立ちます。 既定では、Composerは私有リポジトリについてはgit-over-SSHのURLを生成し、公開リポジトリについてはHTTP(S)のみを生成します。

disable-tls

既定はfalseです。 真に設定すると、すべてのHTTPSのURLが代わりにHTTPで試行され、ネットワークレベルの暗号化は実行されません。 これを有効にすることはセキュリティ上の危険性であり、全く推奨されません。 より良い方法は、php.iniでphp_openssl拡張機能を有効にすることです。 これを有効にすると、secure-httpオプションが暗黙に無効になります。

secure-http

既定ではtrueです。 真に設定すると、HTTPSのURLのみがComposer経由でダウンロードできるようになります。 何かしらへのHTTPアクセスが絶対に必要な場合は無効にできますが、Let's Encryptを使用して無料のSSL証明書を取得する方が一般的にはより良い代替手段です。

bitbucket-oauth

ドメイン名と消費者のリストです。 例えば{"bitbucket.org": {"consumer-key": "myKey", "consumer-secret": "mySecret"}}のように使います。 より詳しくはこちらを読んでください。

cafile

ローカルファイルシステム上の認証局ファイルの配置場所です。 PHP 5.6以降ではシステムCAファイルを自動的に検出できますが、PHP 5.6以降でも、php.iniのopenssl.cafileを介してこれを設定すべきです。

capath

cafileが指定されていない場合、またはそこに証明書がない場合は、capathが指すディレクトリで適切な証明書が探索されます。 capathは正しくハッシュされた証明書ディレクトリでなければなりません。

http-basic

認証するためのドメイン名と、利用者名とパスワードのリストです。 たとえば、このオプションの値として{"example.org": {"username": "alice", "password": "foo"}}を使用すると、Composerはexample.orgに対して認証します。 詳細については、こちらを参照してください。

bearer

認証するドメイン名とトークンのリストです。 たとえば、このオプションの値として{"example.org": "foo"}を使用すると、ComposerはAuthorization: Bearer fooヘッダーを使用して、example.orgに対して認証を行うことができます。

platform

プラットフォームパッケージ（PHP及び拡張機能）を偽装して、運用環境をエミュレートしたり、構成で対象のプラットフォームを定義したりできるようにします。 例えば{"php": "7.0.3", "ext-something": "4.0.3"}です。

これにより、ローカルで実行する実際のPHPバージョンに関係なく、PHP 7.0.3以上を必要とするパッケージをインストールできなくなります。 ただし、依存関係が正しく検査されなくなったことも意味します。 PHP 5.6を実行すると、7.0.3を想定しているため問題なくインストールされますが、実行時に失敗します。 これは、{"php":"7.4"}が指定されることも意味します。 7.4.1を最小のバージョンとして定義するパッケージは使用されません。

したがって、これを使用する場合は、デプロイ戦略の一部としてcheck-platform-reqsコマンドも走らせることをお勧めしますし、より安全です。

ローカルにインストールしていない拡張機能が依存関係に必要な場合は、代わりに--ignore-platform-req=ext-fooをupdate、install、またはrequireに渡して無視できます。 しかし長い目で見れば、今は無視するにせよ必要な拡張はインストールすべきで、1箇月後に新しいパッケージでも必要になると、知らず知らずのうちに本番環境に問題が発生する可能性があります。

拡張をローカルにインストールしているが本番環境ではそうではない場合、{"ext-foo": false}を使ってComposerから意図的に隠すこともできます。

vendor-dir

既定はvendorです。 お好みで違うディレクトリに依存関係をインストールできます。 vendor-dirと以下の全ての*-dirオプション中では、$HOMEと~はホームディレクトリに置換されます。

bin-dir

既定ではvendor/binです。 プロジェクトがバイナリを含む場合、それらのバイナリはこのディレクトリにシンボリックリンクが張られます。

data-dir

既定では、WindowsではC:\Users\<user>\AppData\Roaming\Composer、XDG Base Directory Specificationsに従うunixシステムでは$XDG_DATA_HOME/composer、その他のunixシステムでは$COMPOSER_HOMEです。 現在、過去のcomposer.pharファイルを保存して古いバージョンにロールバックできるようにするためにのみ使用されています。 COMPOSER_HOMEも参照してください。

cache-dir

既定では、WindowsではC:\Users\<user>\AppData\Local\Composer、macOSでは/Users/<user>/Library/Caches/composer、XDG Base Directory Specificationに従うunixシステムでは$XDG_CACHE_HOME/composer、他のunixシステムでは$COMPOSER_HOME/cacheになります。 Composerで使う全てのキャッシュが保管されます。 COMPOSER_HOMEも参照してください。

cache-files-dir

既定では$cache-dir/filesです。 パッケージのzipアーカイブを保管します。

cache-repo-dir

既定では$cache-dir/repoです。 composerの種別用のリポジトリのメタデータと、svn、fossil、github、gitbucketの種別のVCSリポジトリを保管します。

cache-vcs-dir

既定では$cache-dir/vcsです。 git及びhgの種別用のVCSリポジトリメタデータを読み込むためのVCSクローンを保管し、インストールを高速にします。

cache-files-ttl

既定では15552000（6箇月）です。 Composerはダウンロードした全てのdist（zip、tar、……）をキャッシュします。 既定では使われていないものについて6箇月経った後に削除します。 このオプションはこの期間を（秒数で）調整ないし0に設定することで、完全に無効にできるようにするものです。

cache-files-maxsize

既定では300MiBです。 Composerはダウンロードした全ての配布パッケージ（zip、tar、……）をキャッシュします。 ガベージコレクションが定期的に走っている場合、キャッシュで使える最大量です。 最後のキャッシュヒットから時間が経った（比較的使われていない）ファイルが削除されます。

cache-read-only

既定ではfalseです。 Composerのキャッシュを読取専用モードで使うかどうかを決めます。

bin-compat

既定ではautoです。 インストールするバイナリの互換性を決定します。 autoの場合、Composerは、WindowsまたはWSLの場合に.batプロキシファイルのみをインストールします。 fullに設定すると、Windows用の.batファイルとUnixベースのオペレーティングシステム用のスクリプトの両方がバイナリごとにインストールされます。 主にLinux VM内でComposerを実行しているが、WindowsホストOSで使用できる.batプロキシが必要な場合に役立ちます。 proxyに設定すると、ComposerはbashでUnixスタイルのプロキシファイルのみを作成し、WindowsないしWSLでも.batファイルを作成しません。

prepend-autoloader

既定はtrueです。 falseにするとComposerの自動読み込み器は既存の自動読み込み器の前に置かれなくなります。 他の自動読み込み器との相互運用性の問題を修正する際に必要になることがあります。

autoloader-suffix

既定ではnullです。 空でない文字列に設定した場合、生成されたComposerの自動読み込み器の接尾辞に使われます。 nullに設定された場合、可能であればcomposer.lockファイルのcontent-hash値が使われます。 そうでなければ、乱択された接尾辞が生成されます。

optimize-autoloader

既定ではfalseです。 trueの場合、自動読み込み器を吐き出す際に常に最適化されます。

sort-packages

既定ではfalseです。 trueの場合、新しいパッケージを追加したときにcomposer.json中のrequireコマンドでパッケージが名前順に整列された状態に保たれます。

classmap-authoritative

既定ではfalseです。 trueにするとComposerの自動読み込み器はクラスマップからのクラスのみを読み込みます。 暗にoptimize-autoloaderを有効にします。

apcu-autoloader

既定ではfalseです。 trueの場合、Composerの自動読み込み器はAPCuを確認し、拡張が有効になった場合にクラスの有無をキャッシュするのに使います。

github-domains

既定では["github.com"]です。 githubモードで使われるドメインのリストです。 GitHub Enterpriseの準備で使われます。

github-expose-hostname

既定ではtrueです。 falseにするとgithub APIにアクセスするために作られるOAuthトークンがマシンのホスト名ではなく日付になります。

use-github-api

既定ではtrueです。 特定のリポジトリに於けるno-apiキーに似ており、use-github-apiをfalseに設定すると、他のgitリポジトリのように、全てのGitHubリポジトリについて、GitHub APIを使う代わりにリポジトリをクローンするように大域的な挙動を定義します。 しかしgitドライバを直接使うのではなく、ComposerはやはりGitHubのzipファイルを使うことを試みます。

notify-on-install

既定ではtrueです。 Composerではリポジトリが通知のURLを定義できるようにしており、そのリポジトリからパッケージがインストールされたことの通知を受けられます。 このオプションはその挙動を無効にできます。

discard-changes

既定ではfalseで、true、false、またはstashの何れかにできます。 このオプションでは非対話モードでダーティアップデートを制御する既定の方式を設定できます。 trueはベンダーの変更を常に破棄しますが、"stash"は取っておいて再適用しようとします。 よくベンダーを変更する場合は、CIサーバーやデプロイスクリプトにこれを使ってください。

archive-format

既定ではtarです。 archiveコマンドにより使われる既定の形式を上書きします。

archive-dir

既定では.です。 archiveコマンドによる作られる、アーカイブの既定の対象パスです。

例：

{
    "config": {
        "archive-dir": "/home/user/.composer/repo"
    }
}

htaccess-protect

既定ではtrueです。 falseに設定すると、ComposerはComposerのホーム、キャッシュ、データディレクトリに.htaccessファイルを作りません。

lock

既定ではtrueです。 falseに設定すると、Composerはcomposer.lockファイルを作らず、存在している場合は無視します。

platform-check

既定では、PHPのバージョンのみをチェックするphp-onlyに設定されています。 拡張子の存在も確認するには、trueに設定します。 falseに設定すると、Composerは自動読み込み器のブートストラップの一部としてplatform_check.phpファイルを作成せず、requireもしません。

secure-svn-domains

既定では[]です。 安全なSubversionまたはSVNの移送を使用しているものとして信頼し、印を付けるべきドメインの一覧です。 既定では、svn://プロトコルは安全ではないと見なされ、throwされますが、この構成オプションを["example.org"]に設定すれば、そのホスト名でsvnのURLを使用できます。 secure-httpを完全に無効にするよりも優れた安全な代替手段です。

bump-after-update

既定はfalseで、true、false、"dev"、"no-dev"のどれかにできます。 真に設定すると、Composerはupdateコマンドを走らせた後に、bumpコマンドを走らせます。 "dev"や"no-dev"に設定すると、対応する依存関係のみのバージョンが上がります。

allow-missing-requirements

既定はfalseです。 要件から何か欠けているものがあるとき、install時にエラーを無視します。 状況としては、composer.jsonにある最新の変更点に対して、固定ファイルが最新でないときです。

← リポジトリ | 実行時 →

実行時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によるプロジェクトでは利用できません。

← 構成 | コミュニティ →

コミュニティ

既に多くの人々がcomposerを使い、少なくない方々が貢献しています。

貢献

Composerに貢献したいときは、READMEとCONTRIBUTINGのドキュメントを読んでください。

最重要の指針は以下に記述されます。

全てのコードの貢献は、コミット権限をもつ人を含めて、プルリクエストを通じて行われます。 マージ前に中核開発者による承認がなされなければなりません。 これは全てのコードに適切なレビューを確実に行うためです。

プロジェクトをフォークし、機能ブランチを作成し、そしてプルリクエストを送ってください。

一貫性のあるコードベースにするためにコードがPSR-12コーディング規約に従っていることを確認すべきです。

翻訳

日本語訳の改善を歓迎します。 translations/po/ja.poに原文と翻訳の対応があり、このファイルから日本語用のMarkdownファイルtranslations/ja/**/*.mdが生成されます。 したがって後者のMarkdownファイルではなく、前者のGettext POファイルを編集してください。

翻訳はpo4aで管理されています。 npm run translateとするとPOファイルの更新とMarkdownファイルの生成が行われます。 また、package.jsonにはtest:jaとtest:mdのnpm scriptsが定義されています。 test:jaはTextlintにより日本語を検査し、test:mdはmarkdownlintによりMarkdownの構文を検査します。

サポート

IRCチャンネルは<irc.libera.chat>の #composer にあります。

Stack Overflow と GitHub Discussions には両方ともComposerに関係する質問が寄せられています。

有料のサポートについては、Composerに関係するサポートをPrivate Packagistの顧客にチャットとEメールを介して提供しています。

← ランタイム

Composerをプログラムでインストールする方法

ダウンロードページに附記したように、インストーラースクリプトにはチェックサムが含まれており、このチェックサムはインストーラのコードにより変化します。 そのため長い目で見るとこの値に依るべきではありません。

代替案はこのスクリプトを使うことです。 UNIXのユーティリティがあってのみ動作します。

#!/bin/sh

EXPECTED_CHECKSUM="$(php -r 'copy("https://composer.github.io/installer.sig", "php://stdout");')"
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ACTUAL_CHECKSUM="$(php -r "echo hash_file('sha384', 'composer-setup.php');")"

if [ "$EXPECTED_CHECKSUM" != "$ACTUAL_CHECKSUM" ]
then
    >&2 echo 'ERROR: Invalid installer checksum'
    rm composer-setup.php
    exit 1
fi

php composer-setup.php --quiet
RESULT=$?
rm composer-setup.php
exit $RESULT

スクリプトは失敗した場合に1で、成功した場合に0で、それぞれ終了します。 また、何らエラーが起きなければ何も出ません。

別案として、そっくりそのままのインストーラーに頼りたければ、GitHubの履歴から特定のバージョンを取得できます。 GitHubのサーバーを信用できる限りにおいて、コミットハッシュは一意性と認証性を与えるに充分でしょう。 例えば以下です。

wget https://raw.githubusercontent.com/composer/getcomposer.org/f3108f64b4e1c1ce6eb462b159956461592b3e3e/web/installer -O - -q | php -- --quiet

コミットハッシュは https://github.com/composer/getcomposer.org/commits/main にある何かしら最新のコミットハッシュで置き換えると良いでしょう。

何故、比較とワイルドカードが組み合わさったバージョン制約が良くないのか

>=2.*や>=1.1*のようなパッケージの要件でバージョン制約を定義することは、それなりによく見られる誤りです。

ただし本当に意味しているところを考えれば直ちに意味を成さないことに気付かれるでしょう。 >=2.*を分解すると2つに分けられます。

  • >=2はパッケージがバージョン2.0.0以上であるべきだとしています。
  • 2.*は、パッケージがバージョン2.0.0（このバージョンを含む）と3.0.0（このバージョンを含まない）の間にあるべきだとしています。

見ての通り、両方の規則ではパッケージが2.0.0以上でなければならないという事実について合意されています。 しかし、それを書いた時にバージョン3.0.0のパッケージのことを考えていたかについては判定できないのです。 >=2を求めたので照合すべきでしょうか。 それとも2.*を求めたので照合しないべきでしょうか。

こうした理由からComposerはエラーを投げて不当であるとします。 修正するには本当に意味しているところについて考え、これらの規則のうち1つだけを使うことです。

プロキシを隔ててComposerを使う方法

Composerは他の多くのツールと同様、環境変数を使ってプロキシサーバーの使用を制御します。 以下に対応しています。

  • http_proxy - HTTP要求を使うプロキシ
  • https_proxy - HTTPS要求を使うプロキシ
  • CGI_HTTP_PROXY - HTTP要求をCLIの文脈ではないところで使うプロキシ
  • no_proxy - プロキシを必要としないドメイン

これらの名前付き変数は慣習によるもので、公式の標準があるわけではありません。 また異なるオペレーティングシステムやツールに亙る進展や用法については複雑なものとなっています。 Composerでは小文字の名前が望ましいものの、適当な場合には大文字の名前も受け付けます。

使い方

ComposerはHTTPとHTTPSの要求に関して所定の環境変数を必要とします。 例えば以下です。

http_proxy=http://proxy.com:80
https_proxy=http://proxy.com:80

大文字の名前も使えます。

CLIでない使い方

ComposerはCLIでない文脈ではhttp_proxyやHTTP_PROXYを探しません。 このような方法で走らせている場合（例えばCMSや似たような用途に統合しているなど）、HTTP要求用にCGI_HTTP_PROXYを使わなければなりません。

CGI_HTTP_PROXY=http://proxy.com:80
https_proxy=http://proxy.com:80

# cgi_http_proxyも使えます

補足： CGI_HTTP_PROXYは、要求ヘッダの操作を防ぐため、2001年にPerlで導入されました。 この脆弱性が広く報告された2016年に一般に認知されました。 https://httpoxy.org を参照してください。

構文

上の例にある通り、scheme://host:portを使ってください。 スキームが欠けているとhttpが既定になり、ポートが欠けているとhttpやhttpsのスキーム用に80や443の既定になりますが、その他のツールではこれらの値が必要になることがあります。

IPv4用のドットで4つに区切られた記法を使ったIPアドレスとしても、IPv6用に角括弧で囲まれた記法でも、ホストを指定できます。

認証

Composerはscheme://user:pass@host:port構文を使ったBasic認証に対応しています。 利用者名ないしパスワード中の予約されたURLの文字はパーセント符号化されていなければなりません。 例えば以下です。

利用者：me@company
パスワード：p@ssw$rd
プロキシ：http://proxy.com:80

# パーセント符号化された認証
me%40company:p%40ssw%24rd

scheme://me%40company:p%40ssw%24rd@proxy.com:80

補足： 利用者名とパスワードの構成要素は個々にパーセント符号化され、それからコロンの区切り文字で連結しなければなりません。 利用者名には（パーセント符号化されたとしても）コロンを含められません。 なぜならプロキシは最初に見付けたコロンで構成要素を分割するからです。

HTTPSのプロキシサーバー

ComposerはHTTPSのプロキシサーバーに対応しています。 ここでのHTTPSはプロキシに接続されるために使われるスキームですが、PHP 7.3以降かつcurlのバージョン7.52.0以降のみです。

http_proxy=https://proxy.com:443
https_proxy=https://proxy.com:443

特定のドメインでプロキシを迂回する

no_proxy（またはNO_PROXY）を使うと、プロキシが使われるべき「でない」ドメインのコンマ区切りリストが設定されます。

no_proxy=example.com
# example.comとそのサブドメインについてはプロキシを迂回します。

no_proxy=www.example.com
# www.example.comとそのサブドメインについてはプロキシを迂回します。
# example.comについては迂回されません。

ドメインは特定のポート（例えば:80）に制限できます。 またIPアドレスやCIDRの記法でIPアドレスのブロックとして指定することもできます。

IPv6アドレスはhttp_proxy/https_proxyの値と同様、角括弧で囲む必要はありません。 ただしこの形式は受け付けられます。

値を*に設定すると全ての要求に対するプロキシを迂回します。

補足： ドメインの先頭のドットには意味がありません。 処理される前に取り除かれます。

廃止された環境変数

Composerは元々HTTP_PROXY_REQUEST_FULLURI及びHTTPS_PROXY_REQUEST_FULLURIを提供してプロキシの良くない挙動を緩和しようとしていました。 これらは必要ではなくなり、使われることもありません。

パッケージと制約

ComposerのバージョンとVCSのバージョン

Composerはgitのような版管理システムを活用する方向に大きく舵を切っているため、「バージョン」という用語は少し曖昧です。 版管理システムの意味では、「バージョン」は特定のデータを含む特定のファイルの集まりです。 gitの用語法では、これは「ref」もしくは特定のコミットのことです。 これはブランチのHEADやタグで表されることがあります。 あるバージョン……例えばタグv1.1やコミットe35fa0d……がVCSにあることを確認するには、単一の既知のファイルの集まりが欲しいものであり、常に同じファイルが取り寄せられます。

Composerで何気なくバージョンとしてよく指すもの……つまり要件の行でパッケージ名に続く文字列（例えば~1.1や1.2.*）……とは実のところ、より具体的にはバージョン制約です。 Composerはバージョン制約を使い、VCSからチェックアウトすべきrefを調べます（もしくは、composer.json中のversion指定で静的に維持されたライブラリのときは、与えられたライブラリが許容されるか検証します）。

VCSのタグとブランチ

以下の説明では、以下のライブラリリポジトリ例があるとします。

~/my-library$ git branch

v1
v2
my-feature
another-feature

~/my-library$ git tag

v1.0
v1.0.1
v1.0.2
v1.1-BETA
v1.1-RC1
v1.1-RC2
v1.1
v1.1.1
v2.0-BETA
v2.0-RC1
v2.0
v2.0.1
v2.0.2

タグ

通常Composerはタグを扱います（ブランチではありません。 意味するところが分からなければ、版管理システムをご一読ください）。 バージョン制約を書くとき、特定のタグ（例えば1.1）を参照することや、有効なタグの範囲（例えば>=1.1 <2.0や~4.0）を参照することがあります。 こうした制約を解決するため、ComposerはまずVCSに全ての利用できるタグを挙げるよう頼みます。 それからこれらのタグに基づいて利用できるバージョンの内部的な一覧を作ります。 上の例では、composerの内部リストにはバージョン1.0、1.0.1、1.0.2、1.1のベータリリース、1.1の1つ目と2つ目のリリース候補、1.1の最終リリースバージョンなどが含まれます（なおComposerは最終的に有効なバージョン番号を得るため、自動的に実際のタグ名からv接頭辞を除きます）。

ComposerにVCSで利用できるバージョンの完全な一覧ができたら、プロジェクトの全てのバージョン制約に合致する最も大きいバージョンを探します（他のパッケージが自分で指定したものよりそのライブラリのバージョンをより限定されたものを要件とすることがあります。 そのため選ばれるバージョンは入手できるバージョンのうち最大のものであるとは限りません）。 またそのタグのzipアーカイブをダウンロードしてvendorディレクトリの正しい場所に開封します。

ブランチ

タグではなくブランチをチェックアウトしたいときは、特別なdev-*接頭辞（接尾辞のときもあります。後述）を使ってブランチを指す必要があります。 ブランチをチェックアウトすると、ブランチで作業したいと仮定し、実際にリポジトリをvendorディレクトリの正しい場所にクローンします。 タグについては、実際にはリポジトリをクローンせず、正しいファイルを複製します（--prefer-sourceや--prefer-distでこの挙動を変えられます。 インストールオプションを参照してください）。

上の例ではmy-featureブランチをチェックアウトしたいため、require節のバージョン制約としてdev-my-featureを指定することになります。 こうするとmy-liberayリポジトリがvendorディレクトリにクローンされ、my-featureブランチがチェックアウトされます。

ブランチ名がバージョンのように見えるとき、タグではなくブランチをチェックアウトしようとしていることをはっきりしなければなりません。 上の例では2つのバージョンブランチv1とv2があります。 これらのブランチをチェックアウトするにはv1.x-devのようにバージョン制約を指定しなければなりません。 .xは任意の文字列で、v1タグではなくv1ブランチについて書いていることをComposerに伝えます（代替としてブランチにv1ではなくv1.xと名前を付けられます）。 この場合のバージョンのような名前（この場合はv1）を持つブランチでは、dev-を接頭辞として使うのではなく、接尾辞として-devを付けます。

安定性

Composerは次の安定性を（この順で）認識します。 すなわちdev、alpha、beta、RC、stableです。 ここでRCはリリース候補 (release candidate) を表します。 バージョンの安定性は接尾辞で定義されます。 例えばバージョンv1.1-BETAにはbetaの安定性があり、v1.1-RC1にはRCの安定性があります。 そのような接尾辞がないときは、バージョンがstableだと見做します。 例えばv1.1です。 これに加えて全ての番号のブランチに-dev接尾辞を自動的に加え、VCSリポジトリからインポートしたその他全てのブランチにdev-の接頭辞を加えます。 両方の場合とも安定性devが割り当たります。

このことを念頭に置くと、次の節を読む助けになります。

最小安定性

チェックアウトされてプロジェクトに加わるライブラリのVCSの、ファイルに作用する点はもう1つあります。 Composerでは安定性の制約を指定し、正当と見做すタグを制限できます。 上の例で、最終的な公式リリースの前に、バージョン1.1にベータ版と2つのリリース候補が、ライブラリでリリースされていることにご注目ください。 composer installやcomposer updateを走らせるときにこれらのバージョンを取得するには、リリース候補やベータリリース（または所望であればアルファリリース）で良いことをComposerに陽に伝えなければなりません。 これにはプロジェクト範囲のminimum-stability値をcomposer.jsonに使うか、バージョン制約に「安定性フラグ」を使います。 詳しくはスキーマのページをお読みください。

パッケージ制約を書く

Composerでのバージョンの捉え方が分かったところで、プロジェクトの依存関係でバージョン制約を指定する方法についてお話ししましょう。

厳密なパッケージ制約

パッケージの厳密なバージョンを指定できます。 こうすると、このバージョンを、それもこのバージョンだけを、Composerにインストールするよう伝えます。 他の依存関係で違うバージョンが必要なとき、解決器は最終的に失敗し、インストールや更新の処理を途絶します。

例：1.0.2

バージョンの範囲

比較演算子を使うと、正当なバージョンの範囲を指定できます。 正当な演算子は>、>=、<、<=、!=です。

複数の範囲を定義できます。 空白 ( ) やコンマで区切られた範囲は論理積として扱われます。 二重パイプ (||) は論理和として扱われます。 積は和より優先されます。

補足： 境界のない範囲を使うときはご注意ください。 後方互換性を壊すバージョンを予期せずインストールすることがあるからです。 安全のため、代わりにキャレット演算子を使うことをご検討ください。

補足： Composerの古いバージョンでは、単一の棒 (|) は論理和の推奨される代替案でした。 そのため後方互換性のため、単一の棒 (|) は論理和として扱われたままになっています。

例：

  • >=1.0
  • >=1.0 <2.0
  • >=1.0 <1.1 || >=1.2

ハイフン版のバージョン範囲 (-)

含まれるバージョンの集合です。 含まれるバージョンの右部分はワイルドカードが補完されます。 例えば1.0 - 2.0は、2.0が2.0.*になるため、>=1.0.0 <2.1と等価です。 他方で1.0.0 - 2.1.0は>=1.0.0 <=2.1.0と等価です。

例：1.0 - 2.0

ワイルドカードのバージョン範囲 (.*)

*ワイルドカードでパターンを指定できます。 1.0.*は>=1.0 <1.1と等価です。

例：1.0.*

次の大規模リリースの演算子

チルダのバージョン範囲 (~)

~演算子は例で説明するのが1番です。 ~1.2は>=1.2 <2.0.0と等価です。 一方、~1.2.3は>=1.2.3 <1.3.0と等価です。 見て分かる通り、セマンティックバージョニングを尊重するプロジェクトで特に有用です。 よくある使い方は、~1.2のように（こうすると2.0までの全バージョン、ただし2.0は含まれないものにできます）、依存する最小の小規模バージョンの印を付けることでしょう。 理論上は2.0まで後方互換性の破壊はないでしょうから、うまくいきます。 別の見方は、~を使って最小バージョンを指定するというものです。 ただし指定された最後の桁は上げられます。

例：~1.2

補足：: 2.0-beta.1は2.0より厳密には前ですが、~1.2のようなバージョン制約ではインストールされません。 前述の通り、~1.2とは.2が変わることがありますが、1.の部分は固定されるという意味です。

補足： ~演算子にはメジャーリリース番号に関して挙動に例外があります。 つまり、例えば~1は~1.0と同じですが、これは後方互換性を保とうとする上で、メジャー番号を増やせないからです。

キャレットバージョン範囲 (^)

^演算子はとてもよく似た挙動ですが、よりセマンティックバージョニングに密接しており、破壊的でない更新は常に許されます。 例えば^1.2.3は>=1.2.3 <2.0.0と等価です。 2.0までのリリースで後方互換性を壊すものはないからです。 1.0より前のバージョンについては、安全性に留意した動作となっており、^0.3は>=0.3.0 <0.4.0として、^0.0.3は>=0.0.3 <0.0.4として扱います。

これはライブラリのコードを書く際に、最も相互運用性を高くするため推奨される演算子です。

例：^1.2.3

補足： WindowsでPowerShellを使っているとき、例えばcomposer requireコマンドを使う際は、CLIで引数としてキャレットを使うときにエスケープしなければなりません。 キャレットがComposerに確実に正しく渡されるようにするため、例えば^^^^1.2.3のように、4つの連続するキャレット演算子を使わなければなりません。

安定性の制約

安定性を陽に定義しない制約を使うとき、使われた演算子により、Composerは内部的に既定を-devまたは-stableにします。 これは透過的に起こります。

比較で安定リリースのみを陽に検討したいときは-stable接尾辞を加えてください。

例：

制約内部
1.2.3=1.2.3.0-stable
>1.2>1.2.0.0-stable
>=1.2>=1.2.0.0-dev
>=1.2-stable>=1.2.0.0-stable
<1.3<1.3.0.0-dev
<=1.3<=1.3.0.0-stable
1 - 2>=1.0.0.0-dev <3.0.0.0-dev
~1.3>=1.3.0.0-dev <2.0.0.0-dev
1.4.*>=1.4.0.0-dev <1.5.0.0-dev

しかし制約の水準に強制せず様々な安定性を許すには、@<安定性>（例：@dev）のように安定性フラグを使い、与えられたパッケージが既定の最小安定性の設定とは違う安定性でインストールできることをComposerに知らせます。 使える全ての安定性フラグはスキーマのページの最小安定性の節に挙がっています。

まとめ

"require": {
    "vendor/package": "1.3.2", // 1.3.2ぴったり

    // >, <, >=, <= | 上限と下限を指定
    "vendor/package": ">=1.3.2", // 1.3.2以上の全バージョン
    "vendor/package": "<1.3.2", // 1.3.2より小さい全バージョン

    // * | ワイルドカード
    "vendor/package": "1.3.*", // >=1.3.0 <1.4.0

    // ~ | 最後の桁は上げられます
    "vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
    "vendor/package": "~1.3", // >=1.3.0 <2.0.0

    // ^ | 破壊的な変更を許しません（セマンティックバージョニングに従い、メジャーバージョンは固定です）
    "vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
    "vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // メジャーバージョンが0のときは例外
}

パッケージ制約の確認

semver.madewithlove.comを使ってバージョン制約を確認できます。 パッケージ名を埋めると、Composerによりcomposer.jsonファイルに加わる既定のバージョン制約が自動で埋まります。 バージョン制約を調整すると、ツールにより、合致する全てのリリースが強調されます。

困ったときは

以下はComposerを使う上でよくある罠とその回避方法です。

一般

  1. Composerを使っていてどんな問題に直面したときも、必ず 最新版を使って ください。 詳しくはself-updateをご参照ください。

  2. 誰かに尋ねる前に、composer diagnoseを走らせてください。 よくある問題を確認できます。 全て確認したら、次の工程にお進みください。

  3. curl -sS https://getcomposer.org/installer | php -- --checkとしてインストーラの検査を実行し、セットアップに問題がないことを確かめてください。

  4. composer clear-cacheを走らせて、Composerのキャッシュを消去してみてください。

  5. 困ったときはrm -rf vendor && composer update -vとし、必ず composer.jsonから直にvendorをインストール してください。 ただし、既存のvendorのインストールやcomposer.lockの項目についての障害が考えられる場合は除きます。

パッケージが見付かりません

  1. Double-check you don't have typos in your composer.json or repository branches and tag names.

  2. Be sure to set the right minimum-stability. To get started or be sure this is no issue, set minimum-stability to "dev".

  3. Packages not coming from Packagist should always be defined in the root package (the package depending on all vendors).

  4. Use the same vendor and package name throughout all branches and tags of your repository, especially when maintaining a third party fork and using replace.

  5. If you are updating to a recently published version of a package, be aware that Packagist has a delay of up to 1 minute before new packages are visible to Composer.

  6. If you are updating a single package, it may depend on newer versions itself. In this case add the --with-dependencies argument or add all dependencies which need an update to the command.

Package is not updating to the expected version

Try running php composer.phar why-not [package-name] [expected-version].

Dependencies on the root package

When your root package depends on a package which ends up depending (directly or indirectly) back on the root package itself, issues can occur in two cases:

  1. During development, if you are on a branch like dev-main and the branch has no branch-alias defined, and the dependency on the root package requires version ^2.0 for example, the dev-main version will not satisfy it. The best solution here is to make sure you first define a branch alias.

  2. In CI (Continuous Integration) runs, the problem might be that Composer is not able to detect the version of the root package properly. If it is a git clone it is generally alright and Composer will detect the version of the current branch, but some CIs do shallow clones so that process can fail when testing pull requests and feature branches. In these cases the branch alias may then not be recognized. The best solution is to define the version you are on via an environment variable called COMPOSER_ROOT_VERSION. You set it to dev-main for example to define the root package's version as dev-main. Use for example: COMPOSER_ROOT_VERSION=dev-main composer install to export the variable only for the call to composer, or you can define it globally in the CI env vars.

根幹パッケージのバージョン制約

Composer relies on knowing the version of the root package to resolve dependencies effectively. The version of the root package is determined using a hierarchical approach:

  1. composer.json Version Field: Firstly, Composer looks for a version field in the project's root composer.json file. If present, this field specifies the version of the root package directly. This is generally not recommended as it needs to be constantly updated, but it is an option.

  2. Environment Variable: Composer then checks for the COMPOSER_ROOT_VERSION environment variable. This variable can be explicitly set by the user to define the version of the root package, providing a straightforward way to inform Composer of the exact version, especially in CI/CD environments or when the VCS method is not applicable.

  3. Version Control System (VCS) Inspection: Composer then attempts to guess the version by interfacing with the version control system of the project. For instance, in projects versioned with Git, Composer executes specific Git commands to deduce the project's current version based on tags, branches, and commit history. If a .git directory is missing or the history is incomplete because CI is using a shallow clone for example, this detection may fail to find the correct version.

  4. Fallback: If all else fails, Composer uses 1.0.0 as default version.

Note that relying on the default/fallback version might potentially lead to dependency resolution issues, especially when the root package depends on a package which ends up depending (directly or indirectly) back on the root package itself.

Network timeout issues, curl error

If you see something along the lines of:

Failed to download * curl error 28 while downloading * Operation timed out after 300000 milliseconds

It means your network is probably so slow that a request took over 300seconds to complete. This is the minimum timeout Composer will use, but you can increase it by increasing the default_socket_timeout value in your php.ini to something higher.

Package not found in a Jenkins-build

  1. Check the "Package not found" item above.

  2. The git-clone / checkout within Jenkins leaves the branch in a "detached HEAD"-state. As a result, Composer may not able to identify the version of the current checked out branch and may not be able to resolve a dependency on the root package. To solve this problem, you can use the "Additional Behaviours" -> "Check out to specific local branch" in your Git-settings for your Jenkins-job, where your "local branch" shall be the same branch as you are checking out. Using this, the checkout will not be in detached state any more and the dependency on the root package should become satisfied.

I have a dependency which contains a "repositories" definition in its composer.json, but it seems to be ignored.

The repositories configuration property is defined as root-only. It is not inherited. You can read more about the reasons behind this in the "why can't Composer load repositories recursively?" article. The simplest work-around to this limitation, is moving or duplicating the repositories definition into your root composer.json.

I have locked a dependency to a specific commit but get unexpected results.

While Composer supports locking dependencies to a specific commit using the #commit-ref syntax, there are certain caveats that one should take into account. The most important one is documented, but frequently overlooked:

Note: While this is convenient at times, it should not be how you use packages in the long term because it comes with a technical limitation. The composer.json metadata will still be read from the branch name you specify before the hash. Because of that in some cases it will not be a practical workaround, and you should always try to switch to tagged releases as soon as you can.

There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.

Need to override a package version

Let's say your project depends on package A, which in turn depends on a specific version of package B (say 0.1). But you need a different version of said package B (say 0.11).

You can fix this by aliasing version 0.11 to 0.1:

composer.json:

{
    "require": {
        "A": "0.2",
        "B": "0.11 as 0.1"
    }
}

詳細は別称をご確認ください。

構成値がどこから来たものか調べる

php composer.phar config --list --sourceを使うと、それぞれの構成値の出自がわかります。

Memory limit errors

The first thing to do is to make sure you are running Composer 2, and if possible 2.2.0 or above.

Composer 1 used much more memory and upgrading to the latest version will give you much better and faster results.

Composer may sometimes fail on some commands with this message:

PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted <...>

In this case, the PHP memory_limit should be increased.

Note: Composer internally increases the memory_limit to 1.5G.

To get the current memory_limit value, run:

php -r "echo ini_get('memory_limit').PHP_EOL;"

Try increasing the limit in your php.ini file (ex. /etc/php5/cli/php.ini for Debian-like systems):

; Use -1 for unlimited or define an explicit value like 2G
memory_limit = -1

Composer also respects a memory limit defined by the COMPOSER_MEMORY_LIMIT environment variable:

COMPOSER_MEMORY_LIMIT=-1 composer.phar <...>

Or, you can increase the limit with a command-line argument:

php -d memory_limit=-1 composer.phar <...>

However, please note that setting the memory limit using these methods primarily addresses memory issues within Composer itself and its immediate processes. Child processes or external commands invoked by Composer may still require separate adjustments if they have their own memory requirements.

This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the documentation of the fork bomb feature on the cPanel site.

Xdebug impact on Composer

To improve performance when the Xdebug extension is enabled, Composer automatically restarts PHP without it. You can override this behavior by using an environment variable: COMPOSER_ALLOW_XDEBUG=1.

Composer will always show a warning if Xdebug is being used, but you can override this with an environment variable: COMPOSER_DISABLE_XDEBUG_WARN=1. If you see this warning unexpectedly, then the restart process has failed: please report this issue.

"The system cannot find the path specified" (Windows)

  1. Open regedit.
  2. Search for an AutoRun key inside HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor, HKEY_CURRENT_USER\Software\Microsoft\Command Processor or HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Command Processor.
  3. Check if it contains any path to a non-existent file, if it's the case, remove them.

SSL certificate problem: unable to get local issuer certificate

  1. Check that your root certificate store / CA bundle is up to date. Run composer diagnose -vvv and look for Checked CA file ... or Checked directory ... lines in the first lines of output. This will show you where Composer is looking for a CA bundle. You can get a new cacert.pem from cURL and store it there.
  2. If this did not help despite Composer finding a valid CA bundle, try disabling your antivirus and firewall software to see if that helps. We have seen issues where Avast on Windows for example would prevent Composer from functioning correctly. To disable the HTTPS scanning in Avast you can go in "Protection > Core Shields > Web Shield > uncheck Enable HTTPS scanning". If this helps you should report it to the software vendor so they can hopefully improve things.

API rate limit and OAuth tokens

Because of GitHub's rate limits on their API it can happen that Composer prompts for authentication asking your username and password so it can go ahead with its work.

If you would prefer not to provide your GitHub credentials to Composer you can manually create a token using the procedure documented here.

Now Composer should install/update without asking for authentication.

proc_open(): fork failed errors

If Composer shows proc_open() fork failed on some commands:

PHP Fatal error: Uncaught exception 'ErrorException' with message 'proc_open(): fork failed - Cannot allocate memory' in phar

This could be happening because the VPS runs out of memory and has no Swap space enabled.

free -m

total used free shared buffers cached
Mem: 2048 357 1690 0 0 237
-/+ buffers/cache: 119 1928
Swap: 0 0 0

To enable the swap you can use for example:

/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/bin/chmod 0600 /var/swap.1
/sbin/swapon /var/swap.1

You can make a permanent swap file following this tutorial.

proc_open(): failed to open stream errors (Windows)

If Composer shows proc_open(NUL) errors on Windows:

proc_open(NUL): failed to open stream: No such file or directory

This could be happening because you are working in a OneDrive directory and using a version of PHP that does not support the file system semantics of this service. The issue was fixed in PHP 7.2.23 and 7.3.10.

Alternatively it could be because the Windows Null Service is not enabled. For more information, see this issue.

Degraded Mode

Due to some intermittent issues on Travis and other systems, we introduced a degraded network mode which helps Composer finish successfully but disables a few optimizations. This is enabled automatically when an issue is first detected. If you see this issue sporadically you probably don't have to worry (a slow or overloaded network can also cause those time outs), but if it appears repeatedly you might want to look at the options below to identify and resolve it.

If you have been pointed to this page, you want to check a few things:

  • If you are using ESET antivirus, go in "Advanced Settings" and disable "HTTP-scanner" under "web access protection"
  • If you are using IPv6, try disabling it. If that solves your issues, get in touch with your ISP or server host, the problem is not at the Packagist level but in the routing rules between you and Packagist (i.e. the internet at large). The best way to get these fixed is to raise awareness to the network engineers that have the power to fix it. Take a look at the next section for IPv6 workarounds.
  • If none of the above helped, please report the error.

Operation timed out (IPv6 issues)

You may run into errors if IPv6 is not configured correctly. A common error is:

The "https://getcomposer.org/version" file could not be downloaded: failed to
open stream: Operation timed out

We recommend you fix your IPv6 setup. If that is not possible, you can try the following workarounds:

Generic Workaround:

COMPOSER_IPRESOLVE=4環境変数を設定すると、curlをIPv4を使ってドメイン解決するよう強制します。 これはcurl拡張がダウンロード用に使われるときだけ機能します。

Workaround Linux:

On linux, it seems that running this command helps to make ipv4 traffic have a higher priority than ipv6, which is a better alternative than disabling ipv6 entirely:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

Workaround Windows:

On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).

Workaround Mac OS X:

Get name of your network device:

networksetup -listallnetworkservices

Disable IPv6 on that device (in this case "Wi-Fi"):

networksetup -setv6off Wi-Fi

Composerを実行……

You can enable IPv6 again with:

networksetup -setv6automatic Wi-Fi

That said, if this fixes your problem, please talk to your ISP about it to try to resolve the routing errors. That's the best way to get things resolved for everyone.

Composer hangs with SSH ControlMaster

When you try to install packages from a Git repository and you use the ControlMaster setting for your SSH connection, Composer might hang endlessly and you see a sh process in the defunct state in your process list.

The reason for this is a SSH Bug: https://bugzilla.mindrot.org/show_bug.cgi?id=1988

As a workaround, open a SSH connection to your Git host before running Composer:

ssh -t git@mygitserver.tld
php composer.phar update

詳しくは https://github.com/composer/composer/issues/4180 も参照。

Zip archives are not unpacked correctly.

Composer can unpack zipballs using either a system-provided unzip or 7z (7-Zip) utility, or PHP's native ZipArchive class. On OSes where ZIP files can contain permissions and symlinks, we recommend installing unzip or 7z as these features are not supported by ZipArchive.

Disabling the pool optimizer

In Composer, the Pool class contains all the packages that are relevant for the dependency resolving process. That is what is used to generate all the rules which are then passed on to the dependency solver. In order to improve performance, Composer tries to optimize this Pool by removing useless package information early on.

If all goes well, you should never notice any issues with it but in case you run into an unexpected result such as an unresolvable set of dependencies or conflicts where you think Composer is wrong, you might want to disable the optimizer by using the environment variable COMPOSER_POOL_OPTIMIZER and run the update again like so:

COMPOSER_POOL_OPTIMIZER=0 php composer.phar update

Now double check if the result is still the same. It will take significantly longer and use a lot more memory to run the dependency resolving process.

If the result is different, you likely hit a problem in the pool optimizer. Please report this issue so it can be fixed.

2.8.9 2025-05-13

  • バージョン検証でのjson schemaの問題を修正 (#12376)
  • update --lock後に無駄にbump-after-updateし始めてしまう点を直しました (#12371)
  • ZipArchiveを使って解凍するとき、zip爆弾の偽陽性の判定がされてしまう点を直しました (#12409)
  • 空のアーカイブが作られてしまっていた点を直しました (#12408)
  • composer <スクリプト名で実行するとき、実行するスクリプトの出力を削除しました (#12383)

2.8.8 2025-04-04

  • バージョン検証でjson schemaの問題を修正 (#12367)
  • 32ビットのマシンで走らせるときの問題を修正 (#12365)

2.8.7 2025-04-03

  • 依存関係にあるjustinrainbow/json-schemaを6.xに更新 (#12348)
  • Composerが開始する並列プロセスの最大数を制御するCOMPOSER_MAX_PARALLEL_PROCESS環境変数を追加 (#12356)
  • diagnoseコマンドの出力にzstd/brotliの存在有無を追加
  • エラー制御を修正し、非推奨の注意書きで散らからないようにしました (#12360)
  • Composerの実行時に、InstalledVersionsが重複するデータを返していた点を修正 (#12225)
  • --with ...制約の扱いを修正し、別名で置き換えられたパッケージに適用するようにしました (#12353)
  • ベンダーディレクトリ内で、IDEのコードインスペクションに非推奨の警告が出てくる問題を修正 (#12331)
  • json schemaの完全性の問題を修正 (#12332, #12321)
  • パス内の.pharが付くファイルの自動読み込みでの問題を修正 (#12326)

2.8.6 2025-02-25

  • --with[-all]-dependenciesフラグを有効にする環境変数COMPOSER_WITH_DEPENDENCIESとCOMPOSER_WITH_ALL_DEPENDENCIESを追加 (#12289)
  • 特定のスクリプトハンドラがスクリプト名でスキップされるようにするための、環境変数COMPOSER_SKIP_SCRIPTSを追加 (#12290)
  • Avastとcurlの証明書エラーが一緒に検出されたときのエラーヒントを追加 (#9894)
  • アーカイブ作成時の、フォルダ名中のバックスラッシュの扱いを修正 (#12327)
  • containerdの検出を修正し、コンテナでrootの使用についての警告がないようにしました (#12299)

2.8.5 2025-01-21

  • Added build provenance attestation so you can also now download and verify phar files from GitHub releases:

    gh release --repo composer/composer download --pattern composer.phar
gh attestation verify --repo composer/composer composer.phar

  • 非対応のfundingの値により、パッケージの解析エラーが起こっていた点を修正 (#12247)

  • 新しい寄付の書式への対応を修正 (#12257)

  • reload()を使うときの、2.8.4であったInstalledVersionsの退行問題を修正 (#12269)

  • psr-0/psr-4の規則が、vendor/composer/autoload*.phpにおいて不定の順番になっていた点を修正 (#12263)

  • 特定の状況下で、誤って起こっていた警告を修正 (#12284, #12268, #12283)

2.8.4 2024-12-11

  • auditコマンドの終了コードに意味がなかった点を修正しました（脆弱性のとき1、放棄されているときは2、両方では3になりました） (#12203)
  • 複数のクラスが定義されている場合の、プラグインの更新時の問題を修正しました (#12226)
  • phpの設定によって、出力に現れていた重複するエラーを修正しました (#12214)
  • InstalledVersionsがある場合に重複するデータを返していた点を修正しました (#12225)
  • installed.phpを修正し、整列が決定的になるようにしました (#12197)
  • インラインの制約を使っているときにbump-after-updateが失敗する点を修正しました (#12223)
  • create-projectコマンドを修正しました。 パスリポジトリを引数に使った場合、シンボリックリンクを無効にするようになりました (#12222)
  • validate --no-check-publishを修正し、全面的に公開のエラーを隠すようにしました。 無関係なエラーのためです (#12196)
  • composer auditが失敗したとき、auditコマンドが失敗コードを返していた点を修正しました。 ビルドの失敗を引き起こすべきではないためです。 ただ、ビルドの一過程でauditを走らせること自体、あまり感心しません (#12196)
  • curlの使い方を修正し、プロキシが使われているときに壊れたバージョンで多重化を無効にするようにしました (#12207)

2.8.3 2024-11-17

  • Windowsでのプロセス探索の扱いを修正 (#12180)
  • react/promiseの要件で2.xのインストールができるように改めて修正 (#12188)
  • lock:falseがrequireコマンドやbumpコマンドで設定されたときの問題を修正

2.8.2 2024-10-29

  • プロバイダに説明がないとき、プロバイダの提案時にクラッシュしていた点を修正 (#12152)
  • 特定の状況で、スキーマに違反する固定ファイルが作られる問題を修正 (#12149)
  • 相対パスのリポジトリのパスを使う際に、2.8.1で生じたcreate-projectの退行問題を修正 (#12150)
  • ctrl-Cで中断する操作が、テキストプロンプトで機能していなかった点を修正 (#12106)
  • 所有権の違反でgitによりリポジトリが読み込めなかったときに、gitがひとりでに失敗していた点を修正 (#12178)
  • プロキシを介してPHPでないバイナリを実行しているときの、シグナルの扱いを修正しました (#11716)

2.8.1 2024-10-04

  • initコマンドを修正し、使用許諾が与えられなかったときの退行問題を修正しました (#12145)
  • --strict-ambiguousフラグの扱いを修正しました。 全ての問題を報告しないことがありました (#12148)
  • create-projectを修正し、インストールされるプロジェクトファイルのフォルダのパーミッションを継承するようにしました (#12146)
  • 親ディレクトリのcomposer.jsonを使うときのプロンプトが、正しく動かない場合があった点を修正しました (#8023)

2.8.0 2024-10-02

  • 後方互換性についての警告：https_proxy環境変数がhttp_proxyの値にフォールバックする点を修正しました。 2.7.3のリリースノートの通り、フォールバックと警告は削除されました (#11938, #11915)。
  • updateコマンドに--patch-onlyフラグを追加しました。 これにより、更新をパッチバージョンに制限し、全ての依存関係がより安全な方へ更新されます (#12122)
  • auditコマンドに--abandonedフラグに追加しました。 放棄されたパッケージの扱い方が構成されます。 audit.abandoned構成設定を上塗りします (#12091)
  • auditコマンドに--ignore-severityフラグを追加しました。 1つ以上の勧告の深刻度を無視します (#12132)
  • updateコマンドに--bump-after-updateフラグを追加します。 更新が完了した後にbumpを走らせます (#11942)
  • scriptsのうち、どれが追加のCLIの引数を受け取るかを制御する方法を追加しました。 また、コマンドのどこに入れるかも制御できます。 ドキュメントを参照してください (#12086)
  • allow-missing-requirements構成設定を追加しました。 固定ファイルがcomposer.jsonの依存関係を満たさないときのエラーを飛ばすものです (#11966)
  • composer.lockファイルのJSONスキーマを追加しました (#12123)
  • Bitbucketのアプリパスワード対応を改善しました。 リポジトリをクローンしたりソースからインストールしたりする部分です (#12103)
  • reinstallコマンドに--typeフラグを追加し、種別でパッケージを絞り込めるようにしました (#12114)
  • dump-autoloadコマンドに--strict-ambiguousフラグを追加しました。 重複するクラスが見つかったときにエラーコードを返すようにします (#12119)
  • ベンダーファイルが削除されたときにdump-autoloadで出す警告を加えました (#12139)
  • create-projectを走らせる際、欠けている各プラットフォームパッケージに警告を追加しました。 何度も走らせなくていいようにするためです (#12120)
  • sort-packagesが有効のとき、allow-pluginsにパッケージの整列を追加しました (#11348)
  • extやlibのパッケージが欠けているときの、プロバイダパッケージやポリフィルの提案を追加しました (#12113)
  • 最初に全てのパッケージと取り得る更新情報を出力し、対話的なパッケージの更新の選択を改善しました (#11990)
  • 決定論的で（しばしば）論理的な方法で出力を整列し、依存関係の解決の失敗の出力を改善しました (#12111)
  • PHP 8.4のE_STRICTの非推奨の警告を修正しました (#12116)
  • initコマンドを修正し、与えられた使用許諾の識別子を検証するようにしました (#12115)
  • 機能パッケージが2つの主線ブランチのどちらかに由来する可能性があると思われるとき、バージョンの推定を、機能ブランチに基づいてより決定論的になるよう修正しました (#12129)
  • COMPOSER_ROOT_VERSION環境変数の扱いを修正しました。 例えば1.1の扱いは1.2.x-devと同じにし、1.2.0とは違うようにしました (#12109)
  • requireコマンドを修正し、固定ファイルの新しい安定性フラグを飛ばすようにしました。 以前は固定ファイルの不当な差分が生じていました (#12112)
  • php://stdin を修正しました。 Composerをプラグラムで走らせているときに複数回開く可能性がありました (#12107)
  • プラットフォームパッケージの扱いを修正しました。 why-notコマンドと部分更新の部分です (#12110)
  • 2.7.8で入った「transport-options.sslについて、ローカルの証明書の認証がロックファイルに保管されて、可搬でなかった点を修正しました (#12019)」が壊れていたため、差し戻しました。

2.7.9 2024-09-04

  • 制約のある環境でのDockerの検出が壊れていた点を修正しました (#12095)
  • bash補完スクリプトの上流の問題を修正しました。 completionコマンドで更新することをお勧めします (#12015)

2.7.8 2024-08-22

  • outdatedのJSON出力にrelease-ageとrelease-dateとlatest-release-dateを加えました (#12053)
  • PHP 8.4の非推奨の警告を修正しました。
  • ブランチを解決する部分を修正し、#記号を含むものでも機能するようにしました (#12042)
  • bumpコマンドについて、~制約が正しく扱われていなかった点を直しました (#11889)
  • COMPOSER_AUTHが./auth.jsonより優先度が上でなかった点を修正しました (#12084)
  • relative: trueについて、パスのリポジトリのシンボリックリンクが考慮されないことがあった点を修正しました (#12092)
  • キャッシュからの複製について、VirtualBoxの共有フォルダを使うときに失敗することがあった点を修正しました (#12057)
  • PSR-4の自動読み込み順序について、エッジケースの退行問題を修正しました (#12063)
  • 重複するlib-*パッケージにより、peclとcoreのバージョンの同じPHP拡張があるときに問題が生じていた点を修正しました (#12093)
  • transport-options.sslについて、ローカルの証明書の認証がロックファイルに保管されて、可搬でなかった点を修正しました (#12019)
  • メモリに関して、大きなバイナリをインストールするときの問題を修正しました (#12032)
  • archiveコマンドについて、windowsでパスのrealpathが取れないときにクラッシュする点を修正しました (#11544)
  • API: BasePackage::STABILITIESをもって、BasePackage::$stabilitiesを廃止しました (685add70ec)
  • Dockerの検出を改善しました (#12062)

2.7.7 2024-06-10

  • セキュリティ：悪意のあるgitブランチ名を介したコマンドインジェクションに対して修正しました (GHSA-47f6-5gq3-vx9c / CVE-2024-35241)。
  • セキュリティ：悪意のあるgit/hgブランチ名を介した複数のコマンドインジェクションに対して修正しました (GHSA-v9qv-c7wm-wgmf / CVE-2024-35242)。
  • セキュリティ：不正なURLの形式を使って迂回される可能性のあったsecure-http検査を修正しました (fa3b9582c)。
  • セキュリティ：linuxにおけるwindows固有の検査を含むFilesystem::isLocalPathを修正しました (3c37a67c)。
  • セキュリティ：perforceへの引数のエスケープを修正しました (3773f775)。
  • セキュリティ：アーカイブを解凍するときのzip爆弾の扱いを修正しました (de5f7e32)。
  • セキュリティ：Windowsのコマンドの仮引数のエスケープを修正し、エンコーディングの変換の最尤一致によるユニコード文字の濫用を防止しました (3130a7455, 04a63b324)。
  • 隠された規則の名前空間に合致しないクラスに対するPSR違反を修正しました。 これにより新たに違反項目が見つかるかもしれません (#11957)。
  • プラグインがベンダーディレクトリにあるものの、ブランチを変えた後に必要でなくなったり使えなくなったりしたときのUXを修正しました (#12000)。
  • 固定ファイルが古いとき、composer.jsonの新しいプラットフォーム要件が検査されない点を修正しました (#12001)。
  • configコマンドがautoloadキーを削除する機能を修正しました (#11967)。
  • initコマンドでの空のtypeへの対応を修正しました (#11999)。
  • gitの構成でsafe.bareRepositoryがstrictに設定されているときのgitクローンのエラーを修正しました (#11969)。
  • PHP <8.1でネットワークエラーが表示される退行問題を修正しました (#11974)。
  • 一部の警告でのカラーブリードを修正しました (#11972)。

2.7.6 2024-05-04

  • スクリプト制御子が私有コールバックを使う自動読み込み器を加えるときの退行問題を修正しました (#11960)。

2.7.5 2024-05-03

  • removeコマンドにuninstallの別称を加えました (#11951)。
  • 転送で例外を起こすcurlの壊れたバージョン8.7.0/8.7.1のための対処法を加えました (#11913)。
  • Podmanコンテナ内で表示される、rootを使うときの警告を修正しました (#11946)。
  • configコマンドがある状況で正しくオブジェクトを扱っていなかった点を修正しました (#11945)。
  • プロジェクトディレクトリがシンボリックリンクのとき、バイナリプロキシが正しいパスを含んでいなかった点を修正しました (#11947)。
  • イベント制御子（scriptsとplugins）から読み込まれたときに、Composerの自動読み込み器がプロジェクトの自動読み込み器から無視される点を修正しました (#11955)。
  • TransportException（httpの失敗）が個別の終了コードでなかった点を修正しました (#11954)。 100のコードで終わるようになりました。

2.7.4 2024-04-22

  • composer/composerのバージョンpre-2.7.3を要件とするプロジェクトでの退行問題（Call to undefined method ProxyManager::needsTransitionWarning()）を修正しました (#11943, #11940)。

2.7.3 2024-04-19

  • 後方互換性についての警告：https_proxy環境変数がhttp_proxyの値にフォールバックする点を修正しました。 まだそのままになっていますが、警告を伴うようになりました。 https_proxyを空に設定してフォールバックを除くことができるようになりました。 Composer 2.8.0ではフォールバックを削除するため、本警告にご注意ください (#11915)。
  • showコマンドとoutdatedコマンドを修正し、パッケージの一覧を表示するときの先頭のvを除きました。 例えばv1.2.3のような見た目をしていました (#11925)。
  • auditコマンドを修正し、CVEが存在しないときに識別番号を表示しないようにしました。 勧告識別番号が表示されるようになりました (#11892)。
  • project種別を持つパッケージで表示される既定のバージョンが欠けていることについての警告を修正しました。 これらのパッケージは大抵バージョン管理されておらず、循環参照がないためです (#11885)。
  • PHP 8.4の非推奨の警告を修正しました。
  • clear-cacheコマンドを修正し、ローカルのcomposer.jsonのconfig.cache-dir設定を考慮するようにしました (#11921)。
  • statusコマンドが失敗したダウンロードとインストールのプロミスを正しく扱っていなかった点を修正しました (#11889)。
  • GitHubの寄付ファイルのbuy_me_a_coffeeへの対応を追加しました (#11902)。
  • SSHのURLにhgの対応を追加しました (#11878)。
  • 幾つかの環境変数を修正し、整数値がクラッシュを起こさないようにしました (#11908)。
  • IOInterfaceをPSR-3ロガーとして使う際に文脈データが出力されないように修正しました (#11882)。

2.7.2 2024-03-11

  • composer --versionを走らせる際に、PHPのバージョンについての情報を追加しました (#11866)。
  • 根幹のバージョンが見合たらなかったときの警告を追加しました (#11858)。
  • ルート権限で走らせる際に、幾つかの状況下では依然としてプラグインが有効だった問題を修正しました (c3efff91f)。
  • outdated --ignore ...が依然として無視されたパッケージの最新版を読み込もうとしていた問題を修正しました (#11863)。
  • インストールパスの途中でシンボリックリンクが壊れたときの対処について修正しました (#11864)。
  • update --lockが依然として幾つかのメタ情報を間違った内容で更新していた問題を修正しました (#11850, #11787)。

2.7.1 2024-02-09

  • 2.7.0で利用者が出喰わすよくある問題に対して補足を入れるために、プラグインが無効化されたときの警告を幾つか追加しました (#11842)。
  • pharから走らせたときにdiagnoseでのComposerの依存関係の監査が失敗する問題を修正しました。

2.7.0 2024-02-08

  • セキュリティ：危殆化したベンダーディレクトリの内容を介したコードの実行と権限昇格の可能性を修正しました (GHSA-7c6p-848j-wh5h / CVE-2024-24821)。
  • audit.abandoned構成設定の期待値をfailに変更しました。 望ましくなければreportやignoreに設定してください。 またはCOMPOSER_AUDIT_ABANDONED環境変数も使えます (#11643)。
  • update/require/removeコマンドに--minimal-changes (-m) フラグを追加し、--with-dependenciesで部分的な更新を掛けつつ、推移的な依存関係で絶対に必要なものだけを変更できるようにしました (#11665)。
  • outdated/showコマンドに--sort-by-age (-A) フラグを追加し、それぞれリリース日による整列（古いものが最初に来ます）とリリース日の表示ができるようにしました (#11762)。
  • showコマンドで--selfを--installedや--lockedと組み合わせる対応を追加しました。 根幹パッケージを出力されるパッケージの一覧に追加できるようにするための変更です (#11785)。
  • 深刻度の情報をauditコマンドの出力に追加しました (#11702)。
  • composer.jsonにscripts-aliases最上位キーを追加しました。 定義した自前のスクリプトに別称を定義できます (#11666)。
  • 接続が時間切れになったときにIPv4にフォールバックする対応を加えました。 また、IPv4やIPv6に強制するための環境変数COMPOSER_IPRESOLVEも追加しました。 それぞれ4および6に設定できます (#11791)。
  • outdatedの--ignore引数にワイルドカードの対応を追加しました (#11831)。
  • bumpコマンドに、*を>=現在のバージョンに上げる対応を追加しました (#11694)。
  • validateコマンドに、どうあっても照合する可能性のない制約の検出を追加しました (#11829)。
  • とても冗長なモード (-vv) で走らせているときに、パッケージのソース情報をinstallの出力に追加するようにしました。
  • diagnoseコマンドでComposer自体に含まれる依存関係の監査を追加しました (#11761)。
  • diagnoseコマンドの出力にGitHubトークンの失効日を追加しました (#11688)。
  • why/why-notコマンドに非ゼロの状態コードを追加しました (#11796)。
  • show --direct <package>を間接ないし推移的な依存関係で呼び出したときのエラーを追加しました (#11728)。
  • COMPOSER_FUND=0環境変数を追加し、募金の呼び掛けを隠せるようにしました (#11779)。
  • bumpコマンドを修正し、v前置詞が必要なパッケージのバージョンを上げないようにしました (#11764)。
  • ルートユーザーとして非対話的に走らせているときに、プラグインが自動的に無効になる事象を修正しました。
  • update --lockを修正し、distのreference/url/checksumがピン留めされたままになっていなかった点を修正しました (#11787)。
  • 固定ファイルが存在していない場合にrequireコマンドが最後にクラッシュする問題を修正しました (#11814)。
  • 固定された依存関係を監査するときにルートの別称が問題を起こす点を修正しました (#11771)。
  • requireコマンドで4つのコンポーネントでバージョンを扱うときの問題を修正しました (#11716)。
  • Symfony 7の互換性の問題を修正しました。
  • requireコマンドの--dry-runの後、composer.jsonが最新の状態に追従できない問題を修正しました (#11747)。
  • 特定の状況下で警告が間違って表示されていた点を修正しました (#11786, #11760, #11803)。

2.6.6 2023-12-08

  • 要件symfony/consoleから7.xを除外するように修正しました。 Composer 2.6とは互換性が無いからです。 2.7では互換性があるでしょう (#11741)
  • libpqの解析を修正し、可能であれば大域定数を使うようにしました (#11684)
  • 一時制約の失敗があった更新でのエラー出力を修正しました (#11692)

2.6.5 2023-10-06

  • vendorディレクトリに壊れたシンボリックリンクが含まれる場合の失敗を修正しました (#11670)。
  • Composerのzipアーカイブから欠けていたcomposer.lockを修正しました (#11674)。
  • 2.6.4で変わったAutoloadGenerator::dump()の非BCシグネチャを修正しました (cb363b0e8)。

2.6.4 2023-09-29

  • セキュリティ：composer.pharが公開されててアクセスでき、PHPとして実行でき、php.iniでregister_argc_argvが有効なとき、遠隔コード実行の脆弱性がありえた点を直しました (GHSA-jm6m-4632-36hf / CVE-2023-43655)。
  • auditコマンドで放棄されたパッケージのjson出力を直しました (#11647)。
  • プール最適化の工程を効率良くしました (#11638)。
  • show -a <パッケージ名>の効率良くしました (#11659)。