- PHPの自由度はそのまま依存管理の難しさになる
- 他言語との違い
- Composerは決めてくれないツール
- 自由の裏側で起きる問題
- composer.lockの意味
- updateの扱いが難しい理由
- 運用で決めるべきこと
- 注意点：簡単に使えることと安全は別
- まとめ：自由は設計を要求する
PHPの自由度はそのまま依存管理の難しさになる
結論から言うと、PHPのパッケージ管理が難しく感じられる理由は、
Composerが複雑だからではなく、PHPの自由度が高いからです。
PHPは書き方を強制しません。
フレームワークも任意、ディレクトリ構成も任意、実行方法も複数あります。
これは長所ですが、パッケージ管理では責任になります。
なぜなら、前提条件を自分で決めなければならないからです。
他言語との違い
他言語では、ある程度の前提があります。
- Node.js：package.jsonが中心
- Python：仮想環境前提
- Ruby：Bundler前提
しかしPHPは違います。
- フレームワークあり
- フレームワークなし
- 単一ファイル
- 大規模アプリ
すべて同じ言語で成立します。
そのため、依存関係の前提をツールが決めてくれません。
Composerは決めてくれないツール
Composerは次を行います。
- 依存解決
- インストール
- オートロード生成
しかし「どう使うか」は決めません。
例えば、
- vendorをGitに含めるか
- 本番でinstallするか
- buildを分けるか
これらは運用次第です。
つまりComposerは自動化ツールではなく、
選択肢を提供するツールです。
自由の裏側で起きる問題
選択肢が多いと、チームごとに方法が変わります。
- 本番でupdate
- 手動でvendor編集
- lock未管理
どれも動くことがあります。
しかし長期的に問題になります。
典型的な症状：
- 環境差でバグ
- 再現不能エラー
- デプロイ不安定
ツールの問題ではなく、
前提が共有されていない問題です。
composer.lockの意味
composer.lockは単なるキャッシュではありません。
> 依存関係の確定状態
です。
これを共有すると、
誰が実行しても同じ構成になります。
逆に無視すると、
同じコードでも別のアプリケーションになります。
updateの扱いが難しい理由
composer update
便利なコマンドです。
しかし意味は大きいです。
- バグ修正の取得
- 仕様変更の取得
両方を同時に行います。
つまりメンテナンスではなく、
仕様変更に近い操作です。
自由に実行できる分、影響も大きくなります。
運用で決めるべきこと
最低限、チームで共有すべき項目です。
- updateを行うタイミング
- lockの扱い
- 本番デプロイ手順
これがないと、
個人の判断で構成が変わります。
Composer自体は悪くありません。
ルールが無いことが問題になります。
注意点：簡単に使えることと安全は別
Composerはコマンド1つで動きます。
composer require package/name
簡単です。
しかしその影響は広範囲です。
- 依存追加
- バージョン変化
- オートロード更新
コード1行より大きい変更になる場合もあります。
まとめ：自由は設計を要求する
PHPは自由な言語です。
Composerも同じです。
だからこそ、
運用ルールが設計になります。
- いつ更新するか
- どこでインストールするか
- 何を共有するか
これを決めることで、
初めて安定した開発になります。
PHPのパッケージ管理が難しく見えるのは、
ツールが弱いからではありません。
選択の余地が多い分、判断が必要になるからです。
そしてそれは、開発をチーム活動として扱うときに避けられない部分でもあります。
