ひとりまとめ

もろもろのメモ

オレにだけわかるComposer

なんとなく使ってたComposerですが、ついにやっとようやく「あー。そういうことだったのか。早く言ってよ(早く気づけよ)。」となったので、この気持ちを忘れないために備忘録。

自分がプログラムを公開する時ではなく、あくまで公開されてるパッケージを利用する時の視点で、ざっくりと大枠だけ。

 

Composerとは、パッケージの依存関係を解決してくれるやつ

getcomposer.org

「これ便利なライブラリだなー」と思って落としてきて実行してみたら「あれが足りない、これがない」などと言われたこと、いっぱいあります。

必要なものを必要なバージョンで落としてきてくれる、とっても便利な仕組みがこのComposerだという理解。

 

Composerがやってくれる主なこと

・パッケージのインストール

「便利プログラム」= パッケージを、依存するものも含めて入れてくれる。

・パッケージのアップデート

一度入れたパッケージがアップデートしてるかどうかチェックして、新しいのを入れてくれる。

・パッケージの削除

入れてみたものの使わなかったパッケージを、依存するもの含めて削除してくれる。

 

Composerで使うファイル

composer.phar

Composerの本体。これをphp composer.pharなんちゃらってやって実行するか、PATHが通る場所に移してcomposerなんちゃらとやるかは自由。

composer.json

自分のプログラムで使うパッケージとバージョンを記述するファイル。(公開する時とかは、作者情報とかライセンスとかも書き込むけど、使うだけの時はそれらは不要。)

composer.lock

「 「自分が使うパッケージ」が使ってるパッケージ」などを含めた、実際に入れたパッケージが記述するファイル。普段は自分でいじらない。

 

Composerの実行方法

composerの実行にはcompser.pharというのを使う。”composer”で検索すると「composer なんちゃら〜」とか「php composer.phar なんちゃら〜」という記述方法を見るけど、このファイルをPATHが通る場所に置いて使うか、手元(?)に置いて使うかの違い。

compser.pharは、こういう方法で入手できる。

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

あるいは次のページのManual Downloadから。

Composer

こうして落としてきたcomposeer.pharを次のようにPATHの通った場所へ移動させれば、composerというコマンドで実行できるようになる。

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

 

Composerがやってる流れ

パッケージを入れたり削除したりする時、だいたいこんな感じのことをやってるぽげ。

1:composer.jsonをチェック

2:依存するファイルを含めた一覧をcomposer.lockとして作成する

3:composer.lockに書かれたファイルをvendorディレクトリにインストールする

 

Composerでパッケージを入れる方法

大きく2通りあるのだけど、ちょっと挙動が異なる。純粋な意味での「指定したパッケージを入れる」というのは1だと思う。

1:composer require { パッケージ名 }で入れる

composer.jsonに書き込んだ上で、composer.lockを更新して、指定したパッケージを入れる。composer.jsonが存在しなかったら、作ってもくれる。

例:composer require phpunit/phpunit

複数のパッケージに対して次々このようなコマンドを実行しても、composer.jsonには追加をしていってくれるので心配なし。バージョンを指定したい場合は、次のようにする。

例:composer require phpunit/phpunit:6.3.0

 

2:composer.jsonに、使いたいパッケージを記述して入れる

 自分でcomposer.jsonを更新。そのあとに方法が2通りある。

a : composer installを実行

まだcomposer.lockが作られてないとき、つまり一番最初で有効な方法。composer.lockを削除すればいつでも使えるぜ!というのもアリかもしれないけど、果たしてそれが推奨される方法かというとちょっと疑問。

b : composer updateを実行

すでにcomposer.lockがあっても無視して、パッケージをインストールする。

しかし、あくまで「composer.jsonに書かれた全てのパッケージに対して、条件に合う中で一番最新のものに更新する」という挙動なので、厳密には1とは異なる。

あまりないことかもしれないけど、すでに入れていたパッケージがたまたま更新されていたら、それも含めてアップデートしてしまう。(1はあくまでも指定したパッケージしか入れなくて、既存のはチェックしない。)

 

composer.jsonについて

composer initというコマンドを使って対話形式でcomposer.jsonを作ることもできるけど、この場合は自分がパッケージなりプロジェクトを作って配布するために必要なAuthor情報などを記述していくので、単にパッケージを使うだけならここまでは不要っぽげ。

むしろ、ちょこちょこ追加したり削除したりしていくなら、composer.jsonを自分で書き換えず、composer requireとかcomposer removeなどのコマンドを使って書き換えてもらった方が間違いがない気がする。

もし「composer.jsonにこう書いてインストールして使ってね」といったことが書かれてたら、composer.jsonの中のrequireという箇所に書かれてる部分をcomposer require に続けて打ち込めばOK。

 

 composer.jsonが作られると、通常であればその時の最新版のパッケージが入る。そしてそのバージョンも一緒に記録されている。(もちろんrequireするときにバージョンを指定することもできる。)

 

パッケージのアップデート

使っているパッケージをアップデートするには、次のようにする。

composer update

これでパッケージ全てについてアップデートしてくれる。特定のパッケージだけアップデートをすることも可能。

ただし、パッケージを無制限にアップデートするのかというと、そういうわけじゃない。ここで、先ほど出てきたcomposer.jsonの記述内容が効いてくる。composer.jsonに記述してるバージョン指定に従う。意図的に上げ下げする場合はこの部分を変更。

記述のルールについては、こちらの記事が詳しかった。

Composerのバージョン指定方法でのチルダ(~)とキャレット(^)の違い — A Day in Serenity (Reloaded) — PHP, FuelPHP, Linux or something

 

パッケージの削除

次のようにして、特定のパッケージとそれに依存したものを削除できる。

composer remove phpunit/phpunit

(もちろんcomposer.jsonを書き換えてcomposer updateとかでも、消すことは可能は可能。これもパッケージを入れる時と同様、その他のパッケージが意図しないバージョンにアップデートする可能性がある。)

 

composer.lockって?

実際に入れた一連のパッケージのバージョンなどが書かれたファイル。依存するもの含めて全てバージョンを指定してcomposer installするとき必要になる。普段は自分でいじることはないみたい。

 

つまりこういう使い方なんでは?

開発環境では順次必要なパッケージを追加していきそうなので、composer require 〜で個別にパッケージを追加。

一通り終わって本番環境などへ移すとき、composer.jsonとcomposer.lock、必要に応じてcomposer.pharを持ってって、composer installでvendorディレクトリをごっそり入れるってことなんじゃないかなと思ってます。

 

 

今のところ、こんな感じの理解。間違ってたー!という時に、ちょいちょいとアップデートしていく予定です。