パッケージ管理がある前提でPHPは進化した

現在のPHPは「Composerが存在する前提」で設計されている

結論から言うと、現代のPHPは単体の言語として使うことをあまり想定していません。
パッケージ管理（Composer）がある前提で進化してきた言語になっています。

これは大げさではありません。
フレームワーク、ライブラリ、設計規約、開発手順の多くがComposerを前提に作られています。

つまり、Composerは外部ツールではなく、実質的にPHPの一部に近い役割を持っています。

かつてのPHPは「1ファイルで完結」する言語だった

初期のPHPは、次のような使われ方が普通でした。

<?php
echo "Hello World";
?>

FTPでアップロードすれば動きます。
サーバー設定もほぼ不要です。

ライブラリも同じです。

• ファイルをコピー
• include / require

require_once 'mail.php';

これで使えました。
小規模なサイトには十分便利です。

しかしアプリケーションが大きくなると問題が出ます。

• ファイル数の増加
• 読み込み順序依存
• バージョン管理不能

ここまでは「スクリプト言語」としてのPHPでした。

フレームワークの発展が限界にぶつかった

2000年代後半になると、PHPでも大規模アプリケーションが増えます。
そのとき最大の問題になったのが依存関係でした。

フレームワークは次を必要とします。

• ルーティング
• ログ
• テンプレート
• HTTP処理

すべてを自前で実装すると巨大化します。
しかし外部ライブラリを使うと衝突します。

• 同じクラス名
• 読み込み順
• バージョン違い

この時代、フレームワークごとに独自ローダーが存在しました。
互換性はほぼありませんでした。

Composerが変えたのは「共有可能性」

Composerは依存関係の解決だけでなく、
ライブラリを組み合わせて使えるようにしました。

composer require monolog/monolog

これだけでログ機能を追加できます。
そして他のパッケージと共存します。

これにより、フレームワークは次の選択ができるようになりました。

• 全部作る → 不要
• 必要な部品だけ組み合わせる → 可能

つまりPHPは「部品を組み立てる言語」に変わりました。

PSR規約とComposerの関係

重要なのがPSR規約です。
PSR-4のオートロードはComposerが前提です。

require __DIR__.'/vendor/autoload.php';

この1行が標準入口になりました。

PSR規約によって、

• 名前空間
• クラス配置
• インターフェース

が統一されました。
これにより、異なるベンダーのライブラリが連携できます。

つまり、規約は単独では成立せず、
Composerによって実行可能になります。

フレームワークの構造が変わった

現在の主要フレームワークは、
多くの外部パッケージに依存しています。

内部実装の例：

• HTTP処理：別パッケージ
• ログ：Monolog
• DIコンテナ：独立ライブラリ

フレームワーク自体が「統合パッケージ」に近くなりました。

これはComposerがあるから成立します。
もし手動コピー時代なら、依存管理は不可能です。

なぜこれが進化と言えるのか

利点は明確です。

• 再利用性向上
• 保守性向上
• 開発速度向上

1つのライブラリの改善が、複数フレームワークに反映されます。
コミュニティ全体で品質が上がります。

これは単一リポジトリ型の開発では難しい特徴です。

注意点：Composerなしで使うと違和感が出る

まれに、Composerを使わずPHPを使おうとすると違和感が出ます。

• ライブラリの入手が困難
• ドキュメント前提が満たせない
• オートロード前提コードが動かない

これは偶然ではありません。
現在のPHPの多くの資料はComposer前提で書かれています。

まとめ：PHPは単体言語からエコシステムへ変わった

昔のPHPは、単体で完結する言語でした。
現在のPHPは、エコシステムの一部です。

Composerはその中心にあります。

• 依存関係の管理
• コード構造の統一
• ライブラリ共有

これにより、PHPはスクリプト言語の便利さを残したまま、
大規模開発に対応できるようになりました。

PHPの進化は文法の変化だけではありません。
パッケージ管理を前提にした開発文化の変化が、
現在のPHPの姿を形作っています。