質問: プロジェクトをgitで管理しています。 調べてみると下記URLの様に、composerのvedor配下をgitignoreで無視するのが一般的なようで、管理に含めたほうが良いのではと思ってしまうのですが、含めた場合どういったデメリットや弊害が発生するのでしょうか。教えてほしいです。 勿論、管理に含まれるサイズが大きくなってしまうのですが、そこに関してはあまり制限無く開発出来る環境ですので、それ以外の理由などを伺えればと思います。 Composer 再入門 - SlideShare 現状、vendor配下もバージョン管理に含めており、本番環境ではvendor配下を含め全体的にpullする形で運用しているのですが、本番環境上でも`composer update`を実行するものなのでしょうか? 何か間違いや、こうした方が良いなどあれば併せて回答いただけますと助かります。
回答: リポジトリに含めた場合のメリット * 各環境にComposerをインストールする必要がなくなる * 依存パッケージに変更があっても `git pull` するだけで済む * 場合によっては自分で `composer install` するより、リポジトリごと clone/pull した方が速い デメリット * リポジトリのサイズが増えてディスクを圧迫する。 (依存パッケージを削除・変更しても、過去のコミットと一緒に残り続けます) * フレームワークなどではファイル数が数千といった規模で増えるので、普段のGit操作が遅くなる可能性があります(主にWindows)。 * 依存パッケージを変更した際、大量のdiffが生まれます。GithubやBitbucketのようなツールで履歴を見たいときや、マージの確認をする時などには邪魔かもしれません。 * WindowsとLinux系ではvendor/binに生成されるファイルが若干異なります。 * 万が一 `package.json` `package.lock` と `vendor/` のどちらをコミットし忘れることがあると、「手元では動くんですけどね・・・」につながります。vendorのコミットに限らない話ですが、ファイル数が増えることでコミット忘れに気づきにくくなることはあるでしょう。 環境や運用方法、好みによっては上に挙げたデメリットは些細なことかもしれませんが、メリットもそこまで大きくないと感じます。これがPHP製でないツールであれば環境構築がーとも思いますが、PHPの開発・実行環境があるならcomposer.phar置いて実行するだけですから・・・。 Gitを使ったデプロイでなければ、`composer install`まで済んだものをzipなどに固めて、配布することも多いかと思います。 > > 本番環境上でも`composer update`を実行するものなのでしょうか? > > > `composer update` ではなく `composer install` を使った方がいいですね。 ざっくり言うと、前者は依存パッケージの最新バージョンをその場で探してインストールするのに対し、後者は `composer.lock` に記録されたバージョンをインストールします。こうすることで、開発環境と完全に一致したバージョンをインストールすることを保証します。 またパッケージの検索や依存解決の必要がない分、 `composer install` の方が短時間で済みます。