Composerの限界と、それでも使われ続ける理由

結論：弱点はあるが、置き換える理由が成立しない

結論から言うと、Composerには限界があります。
しかしその限界は「使われなくなる理由」にはなっていません。

問題がないから使われているのではなく、問題よりメリットが大きいから使われ続けている、これが実態に近いです。

多くの開発者は、Composerに不満を感じた経験があります。
それでも離れないのは、単なる慣れではありません。

依存解決は万能ではない

Composerは依存関係を解決しますが、すべての衝突を回避できるわけではありません。

例えば、次のようなケースです。

• ライブラリA：package ^2.0 が必要
• ライブラリB：package ^3.0 が必要

両方は同時に成立しません。
この場合、Composerはエラーを出します。

> Your requirements could not be resolved to an installable set of packages.

ここで重要なのは、Composerが壊れているのではない点です。
成立しない設計を検出しているだけです。

つまり、解決できない問題も明確にします。
これは利点でもあり、限界でもあります。

バージョン制約は人間の設計に依存する

"library/package": "^2.3"

この1行で許可される範囲が決まります。
しかし、その範囲が適切かどうかはComposerが判断しません。

• 緩すぎる → 将来壊れる
• 厳しすぎる → 更新できない

どちらも起きます。
依存管理は自動化できますが、設計判断は残ります。

updateの怖さは消えない

composer update

便利なコマンドです。
しかし、実行するたびに状態が変わります。

• バグ修正
• 挙動変更
• 廃止機能

これらが同時に入ります。

つまり、Composerは安定を提供しますが、
更新の安全性までは保証しません。

パフォーマンスの問題

規模が大きくなると、Composerの処理時間が増えます。

• 依存解決が長い
• メモリ使用量が多い
• CI時間の増加

これはよく指摘される弱点です。
ただし、ビルドキャッシュやlock運用で軽減できます。

完全に消えるわけではありませんが、
運用で許容可能な範囲に収まることが多いです。

なぜそれでも使われるのか

理由は単純です。
代替手段がより困難だからです。

Composerが無い場合、次を自分で行う必要があります。

• 依存関係の追跡
• バージョン整合性
• オートロード生成

手動では現実的ではありません。

つまり、完璧ではなくても、
実用的な唯一の解になっています。

エコシステムとの結びつき

Composer単体の話ではありません。

• Packagist
• PSR規約
• フレームワーク

すべて連動しています。
これらを同時に置き換えるのは困難です。

ツールの性能だけで評価できない段階に来ています。

注意点：問題を無視して良いわけではない

使われ続けているからといって、
依存管理を軽く扱えるわけではありません。

• 無計画なupdate
• 制約未設定
• 本番操作

これらは依然としてリスクです。

Composerは安全装置ではなく、
管理を可能にする仕組みです。

まとめ：限界はあるが、基盤として成立している

Composerは万能ではありません。
依存関係のすべてを解決する魔法ではありません。

それでも使われる理由は、
現実的な開発を成立させる最低条件を満たしているからです。

• 再現可能
• 共有可能
• 継続可能

この3つを提供します。

完全ではないから使われないのではなく、
完全でなくても成立するから使われ続けています。

そして多くのプロジェクトにとって、
それが最も重要な性質なのかもしれません。