プロジェクトのルートディレクトリに鎮座する、膨大なファイル群「vendor」。「中身を書き換えていいの?」「なぜGit管理しちゃいけないの?」といった疑問を解消し、使いこなすためのポイントを解説します。
一言でいうと、「外部ライブラリ(パッケージ)の保管場所」です。PHPのパッケージ管理ツールである「Composer」によってインストールされたプログラムがすべてここに入ります。
自分で書いたコード(Appなど)ではなく、「他人が作った便利な道具」を詰め込んだ倉庫のようなイメージです。
⚠️ 絶対ルール:vendorの中身を直接編集しない
vendor内のファイルを書き換えても、composer updateを実行するとすべて上書きされて消えてしまいます。修正したい場合は、後述する「機能5」の方法を使いましょう。
大量のライブラリを手動で1つずつ require するのは不可能です。Composerは vendor/autoload.php というファイルを自動生成します。
require 'vendor/autoload.php';
これを1行書くだけで、vendor内にあるすべてのクラスがどこからでも呼び出せるようになります。Laravelではこれが自動で行われているため、意識せずに外部ツールを使えるのです。
vendor ディレクトリ自体は重すぎるため、通常 Git 管理(GitHubへのアップロード)はしません。その代わりに composer.lock ファイルを共有します。
「新しいクラスを作ったのに認識されない」「ファイルがあるはずなのにNot Foundになる」といった時、vendor 内の読み込みマップを再生成するコマンドが便利です。
composer dump-autoload
困った時の「とりあえずこれ」という呪文として覚えておきましょう。
「vendor内は編集禁止」ですが、設定ファイルやビュー(見た目)を変えたい場合があります。その時に使うのがこのコマンドです。
php artisan vendor:publish
これを実行すると、vendor 内の特定ファイルを config や resources フォルダへ「コピー」してくれます。これなら自由に編集しても update で消えることはありません。
vendor 内のライブラリに脆弱性(セキュリティの穴)がないか、最新のデータベースと照らし合わせてチェックしてくれる機能です。
composer audit
定期的に実行することで、古いライブラリを使い続けるリスクを未然に防ぐことができます。
vendor ディレクトリは、PHP開発の心臓部とも言える重要な場所です。仕組みを理解すれば、環境構築やデバッグのスピードが格段に上がります。
.gitignore に入れる。この3原則を守って、クリーンな開発環境を維持しましょう!