こんにちは、かつコーチです。
前回はPHPの文字化け対処法としてmb_convert_encodingの使い方を解説しました。
今回は少し毛色を変えて、PHP開発を続けていくと必ず名前を聞くことになるComposer（コンポーザー）について解説します。
「Laravelを始めるには、まずComposerをインストールしてください」という文章を見て、「そもそもComposerって何？」と戸惑った経験がある人も多いはずです。
このあとLaravelの学習に進む前提知識として、ここでしっかり整理しておきましょう。
Composerとは何か
ひとことで言うと「PHPのパッケージ管理ツール」
Composerは、PHPで使われるパッケージ管理ツールです。
パッケージ管理ツールとは、他の人が作った便利な機能（ライブラリ）を、簡単にインストール・管理できる仕組みのことです。
「日付を扱いやすくするライブラリ」「メール送信を簡単にするライブラリ」「PDF生成ライブラリ」など、世の中には便利なPHPのコードがすでにたくさん公開されています。
Composerを使えば、これらを自分でゼロから書かなくても、コマンド1つで取り込んで使えるようになります。
なぜComposerが必要なのか
Composerが登場する前は、必要なライブラリを1つずつ手作業でダウンロードし、ファイルをプロジェクトにコピーして、requireで読み込む、という作業を人力で行っていました。
この方法には、次のような問題がありました。
- ライブラリのバージョンを手動で管理しないといけない
- そのライブラリが依存している「別のライブラリ」まで自分で調べて用意する必要がある
- チームメンバー間で使っているバージョンがズレやすい
Composerはこれらを自動化し、「このライブラリを使いたい」と宣言するだけで、関連する依存ライブラリごと一括でインストール・管理してくれます。
私が初めてComposerなしでライブラリを手動導入しようとしたときは、依存関係のエラーが連鎖して収拾がつかなくなり、結局Composerで入れ直した、という苦い思い出があります。
Composerを実際に使ってみる
インストール方法
Composerは公式サイトからインストーラーをダウンロードして導入します。
Macであれば、Homebrewを使うのが手軽です。
brew install composer
インストールが終わったら、ターミナルで次のコマンドを実行し、バージョンが表示されれば成功です。
composer --version
Composer version 2.7.1 2024-02-09 15:26:28
パッケージをインストールしてみる
Composerで最もよく使うコマンドがrequireです。
例えば、日付操作を便利にするnesbot/carbonというライブラリを導入してみましょう。
composer require nesbot/carbon
このコマンドを実行すると、プロジェクトの中に次のようなファイル・フォルダが自動で作られます。
composer.json：プロジェクトが使っているパッケージの一覧（設計図）composer.lock：実際にインストールされたバージョンを固定する記録vendor/：ダウンロードされたパッケージの実体が入るフォルダ
composer.jsonとcomposer.lockの役割の違い
2つのファイルが担う役割
初心者がよく混乱するのが、composer.jsonとcomposer.lockの違いです。
| ファイル | 役割 |
|---|---|
composer.json | 「このパッケージのこのバージョン系統を使いたい」という希望 |
composer.lock | 実際にインストールされた正確なバージョンの記録 |
composer.jsonには、たとえば"nesbot/carbon": "^2.72"のように、ある程度の範囲を持ったバージョン指定が書かれます。
対してcomposer.lockには、実際にその範囲の中から選ばれた「2.72.3」のような、正確なバージョンが記録されます。
かつコーチが実際につまずいた経験
チームで開発していたとき、composer.lockをGit管理に含めずに.gitignoreに入れてしまい、メンバーごとにインストールされるパッケージのバージョンが微妙に異なる、という事態になったことがあります。
「私の環境では動くのに、あなたの環境ではエラーになる」という典型的なトラブルで、原因を探るのに丸一日かかりました。
# ❌ Before：.gitignore に composer.lock を含めてしまう
/vendor/
composer.lock
composer.lockを共有していなかったせいで、composer installを実行したメンバーごとに、微妙に違うバージョンのパッケージがインストールされていたのです。
# ✅ After：vendor/ は除外するが composer.lock はGit管理に含める
/vendor/
vendor/フォルダはGit管理から除外し、composer.lockは必ずGit管理に含める、これがチーム開発における鉄則です。
vendor/はcomposer installを実行すればcomposer.lockの内容通りに誰でも再現できるため、Gitには含めません。
一方composer.lockは「全員が同じバージョンで動く」ことを保証する重要な記録なので、必ず共有します。
requireとinstallの使い分け
新しいパッケージを追加するとき
新しくパッケージを導入したいときはcomposer requireを使います。
composer require guzzlehttp/guzzle
既存プロジェクトをセットアップするとき
他の人が作った、あるいは以前自分が作ったプロジェクトをクローンしてきたときはcomposer installを使います。
composer install
composer installはcomposer.lockを読み込んで、そこに記録されている正確なバージョンのパッケージをvendor/フォルダにインストールします。
Laravelのプロジェクトをダウンロードした直後にvendor/フォルダが存在せず、Class "Illuminate\...\..." not foundのようなエラーが出るのは、まさにこのcomposer installを実行し忘れているケースがほとんどです。
<?php
// ❌ composer install を忘れたまま実行するとエラーになる
require __DIR__ . "/vendor/autoload.php";
// Warning: require(vendor/autoload.php): Failed to open stream: No such file or directory
# ✅ 先に composer install を実行しておく
composer install
vendor/autoload.phpは、Composerでインストールしたすべてのパッケージを自動的に読み込んでくれるファイルです。
このファイルをrequireしておけば、use文だけで各パッケージのクラスを使えるようになります。
Laravelとの関わり
LaravelはComposerで管理されている
次のパートから学んでいくLaravelは、そのフレームワーク自体がComposerで管理されているパッケージの集合体です。
新しいLaravelプロジェクトを作るときも、実はComposerのコマンドが使われています。
composer create-project laravel/laravel my-app
このコマンド1つで、Laravel本体とその動作に必要な多数のライブラリが、依存関係ごと自動でインストールされます。
Composerの基本を理解しておくことで、この後のLaravel学習で「なぜvendorフォルダが必要なのか」「なぜcomposer.jsonを編集するのか」がスムーズに理解できるようになります。
まとめ
この記事のポイント
- ComposerはPHPのパッケージ管理ツールで、外部ライブラリの導入・管理を自動化してくれる
composer.jsonは「使いたいバージョンの希望」、composer.lockは「実際にインストールされた正確なバージョン」を記録するvendor/はGit管理から除外し、composer.lockは必ずGit管理に含めるのがチーム開発の鉄則- 新規導入は
composer require、既存プロジェクトの再現はcomposer installを使う - Laravel自体もComposerで管理されており、この後の学習の前提知識になる
次に読むべき記事
Composerの基本が分かったところで、次はPHPのバージョンアップに伴う非互換エラーへの対処法を見ていきましょう。
→ 次の記事：PHPのバージョンアップで起きやすい非互換エラーとその対処法