【Laravel】git cloneしただけでは、php artisan serveできない

この記事で書くこと

git cloneした後、ブラウザに表示するまでに必要な手順

初めてgit cloneをした時、自分がローカル環境で作ったプロジェクトのようにいつも通りphp artisan serveとしてもブラウザには表示できず、えええ何でダメなの…？？ってなりました。

手順は調べると簡単に出てきたけれど、composerやvendorディレクトリについてそもそも理解していなかったなと痛感しました。

今後もよく使う手順だと思うので、git cloneしてからphp artisan serveするまでの手順と、その仕組みを記録しておきます。

手順の概要

1. [git cloneする](#git cloneする)
2. vendorディレクトリを作る
3. .envファイルを作る
4. アプリケーションキーを初期化する

git cloneする

とりあえずgit cloneから始めます。

GitHubの「Clone or download」より、コピーしたいリポジトリのURLをコピーしておき、次のコマンドを実行します。。

//コピーを保存したいディレクトリに移動しておく
$ git clone コピーしたURL

これでLaravelプロジェクトがローカル環境にクローンされました。

ただしクローンしてきたプロジェクトには、Laravelを動かすのに必要な、

• vendorディレクトリ
• .envファイル

がありません。なのでこれらを準備していきます。

なぜ無いかというと、Laravelでは、これらはGitの管理下におかないからです。（初期状態で.gitignoreに入っている）

Git管理下に置かない理由や、メリット・デメリットは、調べると色々出てきました。
いずれにせよ一長一短あるので、原則Laravel推奨に従うけれど結局はチームやプロジェクトに寄る、ということなのかなと思います。

基本的には、git cloneするとこの2つは無いという前提で説明を続けます。

vendorディレクトリを作る

手順でいうと、下記のコマンドを実行するだけです。

$ composer install

これにより、composer.lockに書かれた情報を基にパッケージやライブラリがまとめてインストールされ、vendorディレクトリに配置されます。

これで目的のvendorディレクトリは作ることができるわけですが、初めての私には分かるような分からないような…という感じだったので、vendorディレクトリやcomposerの仕組みをもう少し詳しくみておきます。

vendorディレクトリとは

Readoubleによれば、「Composerによる依存パッケージが配置される」ところです。
中身を見てみると、こんな感じです。(vendorディレクトリでlsコマンドを使った結果)

ずらーーっと、Laravel本体や各種ライブラリが入っています。
一つひとつの役割は理解できていませんが、Laravel本体も入っていて、これらが無いとLaravelのプロジェクトは動かないことはわかります。（中身の詳細は、またの機会に勉強します…。）

では本題の、Laravelを動かすのに必要なvendorディレクトリをどうやってローカル環境に作るのか。
結論からいうと、Composerを使って、composer.lock(1度目はcomposer.json)に書かれた情報をもとにパッケージやライブラリをインストールします。するとインストールされたものたちはvendorディレクトリに配置されます。

Composerの役割

Composerとは、一言でいうと「PHPのパッケージ・ライブラリの依存管理ツール」です。

Composerを利用する最大のメリットは、ライブラリの依存関係を解決してくれることです。

例えばComposerを使えば、

• ライブラリAをインストールしたい
• しかし、ライブラリAをインストールするにはライブラリBも必要
• なので、ライブラリAもライブラリBもまとめてインストール

というように、依存関係があるライブラリをコマンドひとつでインストールしてくれます。

このようにComposerが依存関係を解決してインストールしてきたパッケージやライブラリが配置されているのが、vendorディレクトリというわけです。

composer.jsonとcomposer.lock

上記の通り、Composerはライブラリやパッケージを管理するツールですが、その管理を担うファイルがcomposer.jsonやcomposer.lockです。これらはLaravelをインストールすると、プロジェクト直下に自動生成されます。

どちらもライブラリ管理を担うという点では同じですが、役割が異なります。

composer.json

最初に使われるのは、composer.jsonです。
composer.json には、必要とするライブラリの種類と、必要なバージョンの条件が書いてあります。

composer.jsonがアプリに配置された状態で、次のコマンドを実行します。

$ composer install

すると、composer.jsonに書かれた情報を基に、パッケージやライブラリがvendorディレクトリ配下にまとめてインストールされます。

composer.lock

このとき同時に生成されるのがcomposer.lockファイルです。
composer install時に実際にインストールされたライブラリの種類とそれぞれのバージョンが書いてあります。

そして2回目以降のcomposer installをしたときには、composer.jsonではなくcomposer.lockを参照してインストールが行われます。

※composer.lockはあくまで自動的に更新されるファイルなので、エディタなどで手動で書き換えてはいけません。

チーム開発における有用性

チーム開発においては、composer.lockをGitでバージョン管理して、各メンバーのローカル環境や本番環境ではcomposer.lockに書かれた情報を基に必要なライブラリをインストールすれば、チームでバージョン等を統一した状態で必要なパッケージをインストールすることができるというわけです。

.envファイルを作る

では次の手順ですが、.envファイルを作成します。
git cloneしてきたプロジェクトには、.env.exampleというファイルが入っているはずです。
これを下記のコマンドでリネームして.envファイルを作成します。

$ cp .env.example .env

DB接続等が必要であれば書き換えます。

アプリケーションキーを初期化する

.env.exampleをコピーして.envを作っただけでは、アプリケーションキーが設定されていませんので、下記のコマンドで初期化を行います。

$ php artisan key:generate

動作確認

ここまでで、ブラウザに表示する準備は整いました。

下記コマンドを実行すれば、動作確認ができるはずです。

$ php artisan serve

## 参考記事