ライブラリ

この章ではライブラリを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があります。

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

Keyboard shortcuts

Composer