ライブラリ

この章は、どのようにあなたのライブラリをComposerでインストールできるようにするかお話します。

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

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

インストール可能なパッケージを作成するために、あなたはそれに名前をつける必要があります。そのためcomposer.jsonにnameを追加してください。

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

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

注意: もしベンダー名に何をつけていいかわからない場合は、あなたのGitHubのユーザネームをつけるといいでしょう。パッケージ名は大文字小文字を区別しないので、全て小文字で単語の区切りはダッシュで行うのが規約です。

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

Composerはプラットフォームパッケージを持っています。これはシステムにインストールされる仮想的なパッケージで、実際にはComposerではインストールされません。これはPHP自身やPHPのエクステンション、システムライブライリを含みます。

phpはユーザのPHPバージョンを表します。これには>=5.4.0のような制約を適用できます。 PHPの64bitバージョンを要求するため、php-64bitのパッケージを指定出来ます。
ext-<name>はPHPのエクステンションを要求します。(コアエクステンション含みます)。バージョニングには全く一致しないことがあります。なので制約には*を設定するのが概ね良い方法です。エクステンションのパッケージ名の例はext-gdです。
lib-<name>はPHPで使われるライブラリのバージョンを制約します。次のものが利用できます: curl, iconv, libxml, openssl, pcre, uuid, xsl.

composer show --platformを使うと、ローカルで利用できるプラットフォームパッケージのリストを得ることができます。

バージョンの指定

いくつかの方法でパッケージのバージョンを指定する必要があります。パッケージをPackagistで公開するときは、VCS(git, svn, hg)からバージョンを推測することができます。この場合、バージョンを指定する必要はありませんし、指定しないことが推奨されます。どのようにバージョンが指定されるかは、タグとブランチを参照してください。

手動でパッケージを作っていて、本当に明示的にバージョンを指定しなければならない場合は、 versionフィールドを追加します。

{
    "version": "1.0.0"
}

注意: バージョンフィールドを明示的に指定することは避けるべきです。なぜなら、タグの値がタグ名にマッチしなければならないからです。

バージョンのように見えるタグでパッケージのバージョンが作成されます。これは'X.Y.Z'または'vX.Y.Z'にマッチする形式で、オプションでサフィックス -patch,-alpha,-betaまたは-RCがつきます。また、サフィックスには数値をつけることもできます。

以下が、有効なタグ名の例になります:

1.0.0
v1.0.0
1.10.5-RC1
v4.4.4beta2
v2.0.0-alpha
v2.0.4-p1

ブランチ

ブランチでパッケージの開発バージョンを作成できます。ブランチがバージョンのように見える場合、そのバージョンは{branchname}-devとなります。例えば2.0ブランチは2.0.x-devバージョンとなります。 (.xはそれがブランチであることを認識するために、技術的な理由で追加されます。 2.0.xブランチも有効で同様に2.0.x-devとなります。ブランチがバージョンのように見えない場合、dev-{branchname}になります。masterはdev-masterとなります。

以下が、ブランチ名の例になります:

1.x
1.0 (equals 1.0.x)
1.1.x

注意: 開発バージョンをインストールするとき、自動でsourceからpullされます。詳細はinstallコマンドを参照してください。

エイリアス

ブランチ名にバージョンのエイリアスをつけることができます。例えば、dev-masterのエイリアスに1.0.x-devつけることができます。これですべてのパッケージで1.0.x-devを要求することができます。

詳細はエイリアスを参照してください。

ロックファイル

お望みならライブラリに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"
    }
}

nameはこのケースでは必須ではありません。このブログをライブラリとして公開しないからです。これは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リポジトリはパッケージリポジトリを指定しrequireフィールドで依存物を定義することで、プロジェクトに追加することができます。

packagistに公開する

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

あなたはmonolog/monologリポジトリを指定していないことに、気づいているかもしれません。これはどのような仕組みでしょうか？答えはpackagistです。

PackagistはComposerのメインパッケージリポジトリで、デフォルトで有効になっています。 packagistで公開されている全てのものは自動的にComposerで利用可能です。 monologはpackagistにあるので、私たち追加のリポジトリ指定なくして依存できるのです。

私たちがhello-worldを世界に共有したいと考えた場合、packagistに公開するのがよいでしょう。本当に簡単にできます。

単純に"Submit Package"ボタンをクリックし、サインアップします。そしてVCSリポジトリのURLを送信してください。 packagistはそのポイントをクローリングをはじめます。完了すると、パッケージはあらゆる人に利用可能になります。

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

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