PHPのcomposerはパッケージを管理するコマンドツールです。
パッケージにはバージョンが付いており、インストールやアップデート時に特定のバージョンを指定することができます。
また、番号だけでなくGitHubなどのブランチを指定する方法もあり、安定版、開発版など開発フェーズも指定できます。
オーソドックスなバージョン指定。番号で指定する。
一番使われるのは、バージョン番号を指定すること。等不等号を使うパターンと記号を使うパターンがあります。
等不等号を使う
| 記号 | 例 |
|---|---|
| = | =1.3.0 |
| < | <2.0.0 2.0.0より小さい |
| > | >2.0.0 2.0.0より大きい |
| <= | <=2.0.0 2.0.0以下 |
| >= | >=2.0.0 2.0.0以上 |
マイナーバージョンを省略すると0になります。
（1.1 -> 1.1.0 1 -> 1.0.0）
また、『〇〇以上、〇〇以下』のように複数条件をつけることもできます。
| ' '（半角スペース） , （カンマ） | AND （かつ） | >=1.0.0 <=2.0.0 >=1.0.0, <=2.0.0 1.0.0以上2.0.0以下。 |
| || | OR （または） | =1.0.0 || =2.0.0 1.0.0 もしくは 2.0.0。 |
不等号はrequire, updateコマンドで使うとエラーになるので使い物になりません。
（composer v2.1.8で実行。）
元々あまり使うものではない。ドキュメント読むまで知らんかったし。
くわしくは後述。
記号を使う
記号を使えば、等不等号と同じように使え見栄えもいいです。こちらを使うのが一般的。
| 1.0.0 | 1.0.1 | 1.0.2 |
| 1.1.0 | 1.1.1 | 1.1.2 |
| 1.2.0 | 1.2.1 | 1.2.2 |
| 2.0.0 | 2.0.1 | 2.0.2 |
| 2.1.0 | 2.1.1 | 2.1.2 |
| 2.2.0 | 2.2.1 | 2.2.2 |
| - （ハイフン） | 1.0 - 2.0 >=1.0.0 <2.1 と同じ。 2.0.2がインストールされる。 |
| * （ワイルドカード） | ワイルドカードを除く数字が同じもの で一番バージョンが高いもの。 1.0.* -> 1.0.2 1.* -> 1.2.2 * -> 2.2.2 （最新版） |
| ~ （チルダ） | チルダの後の番号以上、その番号のひ とつ上（左）の番号+1未満。 ~1.2 >=1.2.0 <2.0 と同じ。 1.2.2がインストールされる。 ~1.2.1 >=1.2.1 <1.3 と同じ。 1.2.2がインストールされる。 |
| ^ （キャレット） | キャレットの後の番号以上、その番号 で0以外の一番左のバージョン+1未満。 ^1.2 >=1.2.0 <2.0.0 と同じ。 1.2.2がインストールされる。 ^0.1 >=0.1.0 <0.2 と同じ。 対象バージョンなし。 |
ひとつ忘れてました。対象範囲のバージョンが見つからなければ最新版をインストールします。バージョン未指定と同じ扱いになる。
Composer公式ドキュメント
等不等号は '=' だけ使える。経験上使うのは *, ^, ~ぐらい。
等不等号は '=' しか使えません。それ以外はエラーが出ます。
composer require monolog/monolog <=2.1
bash: =2.1: No such file or directorycomposer require monolog/monolog<=2.1
bash: =2.1: No such file or directorycomposer require monolog/monolog:<=2.1
bash: =2.1: No such file or directoryこのやり方は古いんじゃないかな？ 使ったこと無いし。
（今回はcomposer v2.1.8で実行。）
また、'=' は通常、コロン（:）を使います。実は半角スペースでも同じ。
それから、記号を使うときは必ずパッケージ名とバージョンの間にコロンを付けます。'=' も結構見るが。
composer require monolog/monolog:^2.1composer require monolog/monolog=2.1.*composer require monolog/monolog ~2.1パッケージのバージョンは、開発時には変更しますがリリースすると頻繁に変えるものじゃありません。
開発時でもメジャーアップデートには躊躇する。パッケージ同士の依存関係で動かなくなることもあるし。
一方、マイナーアップデートはバグ修正とかあるので変更することが多い。
そうなると、*, ^, ~とバージョン固定値を使うことが多くなり、これで事足りる。
番号以外のバージョン
Composerのバージョンには、パッケージの開発フェーズを指定してインストールもできます。
| ⇧ | stable | 安定版。リリース版。 （省略可。番号だけでいい。） |
| ⇧ | RC | リリース候補。 ほぼ正式版。 バグ修正くらいはするが大掛かりな 機能の修正はない。 |
| ⇧ | beta | β版（ベータ版）。 リリース前段階。試用版。 一般公開し、修正点を洗い出す。 |
| ⇧ | alpha | α版（アルファ版）。 開発者やテスター向けのテスト版。 |
| ⇧ | dev | 開発版。 新機能などを見せるために公開する が、ソースコードは頻繁に変わる。 |
stableは番号だけのものと同じ。正式版、リリース版です。それ以外は正式版ではないので、すべてが揃ってるとはかぎりません。
devの次にRCになったり、devの次はstableになったり。自分が見てきた中ではalphaを使ってるのは少ない。
開発フェーズを指定するには '@' を使います。
composer require squizlabs/php_codesniffer:@devcomposer require squizlabs/php_codesniffer:3.0.*@dev'@stable' は番号指定と同じなので未指定でもよく、使うことはありません。
@***はスタビリティ・フラグと言われるもので、ルートパッケージだけに使えるものです。
ルートパッケージは、プロジェクトのルートディレクトリにあるcomposer.jsonにだけ設定できるということ。
開発フェーズはバージョン制約であまり使えない
くわしくは後述しますが、開発フェーズ付きのバージョンには命名規則があり、バージョン番号の後ろにハイフン（-）で後ろにくっつけます。
(バージョン番号)-(開発フェーズ)
また、よく使う有名なパッケージでも見られるんですが、RC1, beta1 など、数字を付けるものがあります。これは命名規則としてはまちがっていて、@を使ったらエラーになります。
composer require monolog/monolog:@beta1
[UnexpectedValueException]
Could not parse version constraint @beta1: Invalid version string "@beta1"もし、命名規則違反のものをインストールしたいときはバージョンのフルネームを指定します。
composer require monolog/monolog:2.0.0-beta1番号にワイルドカード（*）などを使って曖昧な指定もできません。
パッケージにない開発フェーズのバージョンを指定したら、stableの最新バージョンをインストールします。
たとえば、betaがないのに '@beta' を使うとか。
stable以外で数字をくっつけるものをよく見るが、命名規則は間違っている。
（'@' は使えない。）
有名なパッケージでも頻繁に使われているので正しい名前だと勘違いしやすい。
これをインストールするにはバージョンのフルネームを指定する。
ComposerのバージョンはGitと連携している
パッケージのバージョンは、VCS（Version Control System: バージョン管理システム）を利用することに重きをおいています。
VCSの代表的なものはGit。サービスとしてはGitHubが有名ですね？
ようは、Composerのリポジトリはソースコードは持ってなくて（もしくはGitをクローンして）、GitHubなどにアップされたパッケージをインストールしているってこと。
Composerでいうバージョンは、バージョン制約というルールに従ってインストールします。さっき命名規則と言ってたものですね？
Composerのバージョンが見ているのはVCSのタグ
composerで指定するバージョン番号はGitなどのVCSのタグです。開発フェーズで@が使えないときはフルネームを指定すればいいと言ったのはタグ名を指定するのと同じこと。
命名規則がまちがってても、タグで指定すれば 1.0.0-RC1 などもインストールできます。
VCSのブランチを指定してインストール
タグだけでなく、VCSのブランチを指定することもできます。
ブランチ名の前に 'dev-' をつければOK。
| ブランチ名 | Composerで使うブランチ名 |
|---|---|
| master | dev-master |
| main | dev-main |
| develop | dev-develop |
composer require monolog/monolog:dev-mainGitは主要ブランチがmasterでしたが、mainに変わってきています。
今後はmainが主流になる。
Composerはパッケージのバージョンリストを作ってるだけ
composerは、GitHubなどにあるパッケージのリポジトリから、バージョン制約にのっとってタグからバージョンのリストを作り、'dev-' を付けたブランチのリストを作成します。
ここで制約に合わないバージョン名は除外。だからそれを指定してもエラーになったり最新のstableをインストールします。
（@beta1とか@RC2が効かないのも同じ。）
Gitのタグでは 'v1.0.1' のようにvで始まる書き方をよくしますが、composerはこの
'v' を削除してバージョン番号を作成します。
（タグ 'v1.0.1' は '1.0.1' として認識。*, ^, ~ で範囲指定も可。）
これだけはやってくれるらしい。
composerのリポジトリはrequireでインストールを受け付けると、指定されたバージョンに対応したGitのブランチやタグからソースコードをダウンロードします。
実はcomposerの内部はVCSを中継しているだけ。
たとえば、monolog/monologはComposerのパッケージリストのサイトにもGitHubにもあります。
両方を比べれば、タグとブランチの連携ができてることが確認できます。
