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.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になります。

省略可能です。

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