Original article:https://blog.packagist.com/composer-2-0-is-now-available/
もはやPHPには欠かせないパッケージマネージャであるComposerですが、2020/10/24にComposer2.0.0がリリースされました。
2012年のリリース以来初めてのメジャーバージョンアップということで、多くの改善や新機能が盛り込まれており、そして互換のない変更点もわずかに存在します。
以下は公式でもアナウンスされている、Jordi Boggianoによる紹介記事Composer 2.0 is now available!の日本語訳です。
Composer 2.0 is now available!
1/ What's new?
何が新しくなったの？
変更点や改善点は非常に多岐にわたるので、全てを知りたい場合は変更履歴を確認してください。
ここではいくつかの重要なポイントについて解説します。
Performance improvements
Composerとpackagist.org間の通信で使用されるプロトコルや依存関係の解消などについて、依存評価の最適化、Curlの並行ダウンロードなどを用いて、全面的に改修を行いました。
これにより、速度とメモリ使用量の両方において大幅な改善を行うことができました。
実際にどのくらいになるかはユースケースによりますが、幾つかのプロジェクトでは50%以上の改善がみられました。
きっとComposer2を初めて試した時には驚くことでしょう。
また、require/removeや一部分だけの変更については、メタデータを変更されたところだけ取ってくるようにしたため、非常に高速化しています。
ext-curlを有効活用したComposer2は、初回インストール速度が6割も改善している。
Architectural changes and determinism
依存関係の解決を行う方法をリファクタリングしました。
vendorディレクトリの現在のローカルの状態が、updateに影響しないようになりました。
installはupdateが終わった後で実行されます。
これにより、全てのネットワークを使う動作は最初に実行されるようになりました。
さらに、これらは可能であれば同時に実行されます。
これにより、installの途中でネットワークエラーが発生した場合でも、中途半端に壊れたvendorディレクトリが残らないようになります。
Runtime features
プラットフォームチェックを追加しました。
vendor/autoload.phpが呼ばれた際、現在のPHPバージョンやエクステンションが対応したバージョンであるかをチェックし、一致していなければエラーにします。
これはデフォルトで有効になっています。
新たにComposer\InstalledVersionsクラスが追加されました。
全てのプロジェクトでオートロードされ、現在の環境に入っているパッケージおよびバージョンを確認することができるようになります。
詳細はドキュメントを参照してください。
あなたがこれらに依存したコードを書きたいのであれば、composer.jsonに"composer-runtime-api": "^2.0"と記述してください。
これはComposerが提供する仮想パッケージで、Composer 2.xからの対応となります。
Error reporting improvements
常に何もかもがうまくいくとは限らないため、依存関係が解決できない場合に表示されるエラー報告の内容を改善しました。
失敗する理由はいくらでも存在するのでここで具体例を示すことはしませんが、メッセージは簡潔に、明確になり、また繰り返しが少なくなったことに気が付くと思います。
Partial updates with temporary constraints
一時的に何かをテストしたり、バグフィックスを待ったりするために、特定のパッケージを特定のバージョンにアップグレード・ダウングレードしたくなる場合があるでしょう。
たとえばcomposer update vendor/package:1.0.*とか1.0.12などと記述することで、該当のvendor/packageのみをこの制約にマッチするバージョンにアップデートすることができます。
このときにcomposer.jsonが更新されることはなく、ロックファイルが期限切れになったりすることもありません。
制約を付けたうえで依存関係を完全に更新したい場合は、update --with vendor/package:1.0.*とすることで、追加制約を保ちつつ更新することができます。
2/ How easy is it to upgrade?
アップグレードは簡単ですか？
我々の目標は、全てのComposerユーザーが迅速かつスムーズにComposerをアップグレードできるようにすることです。
アップグレードの恩恵は大きいので、皆に体験してもらいたいと思っています。
そのために、幾つかの対応を行いました。
・Composer 2.0は、1.x同様PHP5.3以降をサポートしている
・composer.lockは互換性があり、2.0へのアップグレードおよび1.xへのダウングレードが可能
・ほとんどのコマンドや引数に変更はなく、既存コマンドのほとんどはComposer 2.0でも使用可能
Composer1.xでcomposer self-updateを実行すると、新しいバージョンの安定版Composerが利用可能であることを通知します。
composer self-update --2を実行することで実際にアップグレードすることができます。
何らかの問題が発生した場合は、composer self-update --1ですぐに元に戻すことができます。
これによって、誰もが新バージョンをとりあえず試してみることができるでしょう。
インストーラスクリプトを使用してComposerを自動アップデートしている場合は、引数に--1を加えることで引き続きComposer1.xを使い続けることができます。
ただし、Composer1.xは今後長くメンテナンスされ続けるわけではないので、いずれはアップグレードすることをお勧めします。
3/ Backwards compatibility breaks?
ここでは、アップグレード時にトラブルが発生しやすい作業について紹介します。
Plugins
おそらく、最も多くの人にとって最大の問題になる部分だと思われます。
プラグインはComposer2をサポートするために更新されなければなりませんが、中にはまだその準備ができていないものも存在するでしょう。
Composer2はそのようなプラグインにはサポートされていない旨の警告を出したり、あるいはインストールに失敗するので、深く考えずにとりあえず試してみて様子を見てみるのが早いでしょう。
platform-check feature
新機能であるプラットフォームチェック機能は、ランタイムのPHPバージョンと、使用している拡張機能が依存しているバージョンが合っているかどうかをComposerがチェックします。
対象外だった場合はオートローダはエラーを出して停止します。
本番環境へのデプロイ時に問題が発生しないようにするには、ビルドプロセスの一部としてcomposer check-platform-reqs --no-devを実行するとよいでしょう。
Repository priority
優先順位の高いリポジトリにパッケージが存在する場合、優先順位の低いリポジトリにあるパッケージは完全に無視されるようになりました。
Composer2を使っていてパッケージが見つからない問題に遭遇した場合は、優先順位のマニュアルを参照してください。
Invalid PSR-0 / PSR-4 configurations
PSR-0 / PSR-4として正しくない形式のオートロードは、Composer1.10で警告が発生するようになり、Composer2ではオートロードされなくなりました。
大抵の場合、これらの警告はオートロードを意図していないクラスに対して発生するものなので、実質的な問題は発生しないと思われますが、アップグレード前に警告を一掃しておいた方が無難でしょう。
もっと詳しく知りたい場合は、UPGRADEのうち、自分が対象となっているセクションを読むことをお勧めします。
4/ What's next?
Comoposer2.0に全てを注ぎ込んだため、今のところ次のロードマップはありません。
重要なこととしてひとつ、今後サポートするPHPバージョンについて説明したいと思います。
上記で述べたように、Composer 2.0はPHP5.3をサポートしていますが、これは時代遅れのバージョンであり、このためにコードのメンテナンスが非常に困難になっています。
全てのComposerユーザがComposer 2.0にアップグレードできるように対応しましたが、今後のマイナーバージョンアップによって、EOLとなったPHPバージョンのサポートを打ち切る予定です。
Composer 2.1では、最終的に含まれる機能によってはPHP5.3のサポートが継続されるかもしれません。
しかし、Composer 2.2ではPHP7.1.3以前のバージョンのサポートは廃止される予定です。
我々の統計によると、90%以上のComposerユーザは引き続きComposerを使用可能です。
ただし、PHPのバージョンを上げることが困難なユーザのために、重大なバグ・セキュリティフィックスは当面は2.0.xにも提供していく予定です。
Composer 1.xについては、遠からずEOLとなります。
今後もクリティカルなものについては修正を提供する予定ですが、速やかに2.xに移行することをお勧めします。
最後に、リリースのために尽力してくれた皆様に感謝します。
Composer2.0には、28人から1100以上のコミット、150以上のissueとプルリクがありました。
そしてテストやプルリクのレビューを行ってくれた人にも感謝します。
最初のコミットから約2年、たいへんな努力の積み重ねがありました。
また本プロジェクトに資金と時間を提供してくれたPrivate Packagistにも感謝します。
皆様がComposerを使ってもらえることを心から願っています。
感想
yarnもpnpmもその他多くのライブラリもだけどさ、どうして真っ先にインストール速度とかいうどうでもいいところを持ってくるんだろう。
ほぼ全ての開発者は開発環境構築マニアではないので、インストールなんて最初の一回やったらそれで終わりです。
PHPの場合は、コンパイル言語みたいにファイルを更新するたびにビルドしたりする必要もないのでなおさらです。
さらにComposerコマンドは、make等と違ってそもそもたいして時間がかかりません。
それにどうせコマンド入力した後はコーヒーを飲んでるだけなので、90秒が40秒に縮まったとか言われてもコーヒーを飲む時間が減るだけです。
インストール速度が50%アップするより、毎回の実行速度が1%アップした方がよっぽど嬉しいってものです。
なお実際試してみたところでは、実行速度は早くなっているのか遅くなっているのかわかりませんでした。
ロジックやDBアクセスに比べたら誤差みたいなものなので、いずれにせよ隙間に消える程度の速度差しかないようです。
しかし、なんといっても素晴らしいのが、コマンドひとつで簡単にアップグレード/ダウングレードできる機能です。
動くかどうかわからないからアップデートに躊躇する、なんてときにとりあえず試してみることができるのは非常に便利です。
またremoveのドライランやオフラインインストールなど、ここには書かれていない大量の機能も追加されているようです。
色々研究してみるのも楽しいかもしれません。
総合的には、とりあえずアップグレードして問題が発生しないかぎりそのまま運用する、で間違いないでしょう。
アップグレードしてみた
手元のローカルXAMPPで試してみたところでは、何一つ抵抗もなくアップグレード・ダウングレードすることができました。
コマンドも僅か数秒で実行完了したため、コーヒーを入れる暇すらありません。
プラグインも入れてないし、あまり変なライブラリも使ってないからというのもあるかもしれませんが、適当に動かしてみたところでは、特に影響を受けるアプリケーションもなさそうでした。
普通の環境では即Composer2.0にしてしまって全く問題なさそうです。
PHPの実行速度については、上記のとおりよくわかりませんでした。
むしろ0.001秒くらい遅くなったような気がするのですが、もしかしたら気のせいかもしれません。