ツイート
シェア
LINEで送る
B! はてぶでブックマーク
Pocketでブックマーク
RSSフィード

PHP composer, パッケージのインストールでバージョンを指定するいろいろな方法。

php
イラストダウンロードサイト【イラストAC】
の画像をもとに加工しています。

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.01.0.11.0.2
1.1.01.1.11.1.2
1.2.01.2.11.2.2
2.0.02.0.12.0.2
2.1.02.1.12.1.2
2.2.02.2.12.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 require monolog/monolog <=2.1
bash: =2.1: No such file or directory
composer require monolog/monolog<=2.1
bash: =2.1: No such file or directory
composer require monolog/monolog:<=2.1
bash: =2.1: No such file or directory

このやり方は古いんじゃないかな? 使ったこと無いし。

(今回はcomposer v2.1.8で実行。)

また、'=' は通常、コロン(:)を使います。実は半角スペースでも同じ。

それから、記号を使うときは必ずパッケージ名とバージョンの間にコロンを付けます。'=' も結構見るが。

composer require monolog/monolog:^2.1
composer require monolog/monolog=2.1.*
composer require monolog/monolog ~2.1

パッケージのバージョンは、開発時には変更しますがリリースすると頻繁に変えるものじゃありません。

開発時でもメジャーアップデートには躊躇する。パッケージ同士の依存関係で動かなくなることもあるし。

一方、マイナーアップデートはバグ修正とかあるので変更することが多い。

そうなると、*, ^, ~とバージョン固定値を使うことが多くなり、これで事足りる。

番号以外のバージョン

Composerのバージョンには、パッケージの開発フェーズを指定してインストールもできます。

stable安定版。リリース版。
(省略可。番号だけでいい。)
RCリリース候補。

ほぼ正式版。
バグ修正くらいはするが大掛かりな
機能の修正はない。
betaβ版(ベータ版)。

リリース前段階。試用版。
一般公開し、修正点を洗い出す。
alphaα版(アルファ版)。

開発者やテスター向けのテスト版。
dev開発版。

新機能などを見せるために公開する
が、ソースコードは頻繁に変わる。

stableは番号だけのものと同じ。正式版、リリース版です。それ以外は正式版ではないので、すべてが揃ってるとはかぎりません。

devの次にRCになったり、devの次はstableになったり。自分が見てきた中ではalphaを使ってるのは少ない。

開発フェーズを指定するには '@' を使います。

最新のdevをインストール
composer require squizlabs/php_codesniffer:@dev
特定のバージョン番号のdevをインストール
composer 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公式ドキュメント

Stabilities

Stability Constraints

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で使うブランチ名
masterdev-master
maindev-main
developdev-develop
composer require monolog/monolog:dev-main

Gitは主要ブランチが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にもあります。

両方を比べれば、タグとブランチの連携ができてることが確認できます。

前の投稿
PHP, composerをインストールする方法。必須。絶対に入れよう!
PHP composer, あれ?開発版がインストールされる。設定がそうなってた。
次の投稿

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください