WSLのUbuntu内でPHP・ComposerがLaravelを動かし、Node.js・npm・ViteがCSSとJavaScriptをビルドする構成

Laravelの準備ではComposerとnpmの両方を使いますが、私にはnpmを使う理由が分かりませんでした。
そこで、Composerが管理するものとの違いを確認しながら、導入手順を整理します。

PHPとComposerを準備したら、Laravelのプロジェクトを作成し、ローカルで起動するところまで進めます。
Laravelの標準的な画面開発では、PHP側の準備に加えて、CSSやJavaScriptをまとめるためのNode.js・npmも使います。
この記事では、WSLのUbuntuにNode.js 24 LTSとLaravel 13を導入し、ビルド、初期テスト、HTTP応答を確認する手順を紹介します。

対象は、WSL 2のUbuntuでPHP 8.3以上とComposerを使える方です。
WSL自体やPHP・Composerの導入は済んでいることを前提にします。
コマンドはすべてUbuntuのターミナルで実行し、プロジェクトはUbuntu側の作業フォルダーに作成します。
環境と確認結果は2026年10月時点のものです。

PHP側と画面側で使うツールを確認する

Composerは、PHPのライブラリと、それらが必要とする別のライブラリを管理するツールです。
Laravel本体もComposerで導入します。
一方、npmはJavaScript側のパッケージを管理します。
今回npmを使うのは、画面用のCSS・JavaScriptをビルドするViteなどを導入し、動かすためです。

ビルドとは、開発中のファイルを処理して、ブラウザーへ配信するファイルを作る作業です。
Laravelの標準構成では、この作業にViteを使います。
Node.jsは、Ubuntu上でViteを実行するための環境になります。

今回の各ツールの役割は、次のとおりです。

ツール 今回の役割
PHP Laravelのプログラムを実行する
Composer Laravel本体とPHPライブラリを導入する
Node.js Viteなど、画面用の開発ツールを実行する
npm JavaScript側の依存パッケージを導入し、ビルドを実行する
nvm Ubuntuで使うNode.jsの版を管理・選択する
Vite CSS・JavaScriptをブラウザーへ配信するファイルにまとめる

例えば、PHPのライブラリはComposerでvendor/へ、Viteなどはnpmでnode_modules/へ導入します。
composer.jsonとpackage.jsonは、それぞれ何を導入するかを記したファイルです。
同じLaravelプロジェクト内にありますが、担当するパッケージが異なります。

今回のようにnpm run buildでファイルを用意した後は、Node.jsを起動し続けて画面を配信する構成にはしていません。
Laravelの開発サーバーを起動し、ブラウザーは生成されたCSS・JavaScriptを読み込みます。
このビルドと開発中のViteサーバーの違いは、Laravel公式のViteガイドでも説明されています。

まず、Ubuntu側でPHPとComposerが使えるか確認します。
Windows側に導入済みでも、Ubuntu側で使えるとは限りません。

php --version
composer --version

どちらも版が表示されれば、次へ進みます。
検証時はPHP 8.3.6、Composer 2.7.1でした。
PHPの表示が同じ8.3.6でもUbuntuの修正パッケージが異なる場合があるため、OSの更新も適用しておきます。

nvmを用意する

Ubuntuのターミナルで、nvm・Node.js・npmが既に使えるか確認します。

command -v nvm
command -v node
command -v npm

nvmはシェルの関数なので、読み込まれていればnvmと表示されます。
Node.js・npmは実行ファイルの場所が表示され、見つからないものは何も表示されません。

既にnvmを導入していても、今のターミナルで読み込まれていないことがあります。
~/.nvm/nvm.shがある場合は、次を実行してから再確認します。

source ~/.nvm/nvm.sh
command -v nvm

nvmが未導入の場合は、nvm公式の導入手順を確認します。
次は公式READMEを参照した導入例です。
初回のnvm導入は、今回の作業環境で新しく実行した手順ではありません。

sudo apt-get update
sudo apt-get install curl ca-certificates
curl -fsSLo /tmp/nvm-install.sh https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.8/install.sh
less /tmp/nvm-install.sh
bash /tmp/nvm-install.sh

lessで取得したスクリプトの内容を確認し、qで閉じてから実行します。
nvmの導入にsudoは付けません。
導入後はUbuntuのターミナルを開き直し、command -v nvmでnvmと表示されることを確認します。

nvmを使わずに導入したNode.jsがある場合は、現在の導入方法を確認してから進めてください。
既存のNode.jsを削除する操作は、この手順には含めていません。

Node.js 24 LTSを導入・選択する

nvmが使える状態になったら、Node.js 24を導入して選択します。
npmも一緒に入ります。

nvm install 24
nvm use 24
node --version
npm --version

node --versionがv24.で始まり、npm --versionでも版が表示されれば、必要なツールを使える状態です。
検証時に取得した版はNode.js v24.21.0、npm 11.19.0でした。
nvm install 24で取得される細かな版は、実行時期によって変わります。

新しいターミナルでも24系を既定にしたい場合は、次を実行します。
ほかのプロジェクトでもnvmを使っている場合は、既定の変更が影響する点を確認してください。

nvm alias default 24

Node.jsのサポート状況は、公式のリリース情報で確認できます。

ComposerでLaravel 13のプロジェクトを作る

プロジェクトを置きたい親フォルダーへ移動し、次を実行します。
learning-appは新しく作成するフォルダー名で、既存のアプリとは別の、まだ存在しない名前を指定してください。

composer create-project laravel/laravel learning-app '^13.0' \
  --prefer-dist --no-interaction
cd learning-app
php artisan --version

^13.0でLaravel 13系のプロジェクトを指定しています。
php artisanは、そのプロジェクトのLaravel用コマンドを実行する入口です。
ここでは--versionを付け、導入されたLaravelの版を確認します。

検証時の表示はLaravel Framework 13.35.0でした。
同じコマンドでも、取得時点によって導入される版や依存パッケージは変わります。

プロジェクト作成時には、.envという設定ファイル、アプリの鍵、database/database.sqliteも用意されました。
SQLiteは、データをファイルに保存するデータベースです。
今回の初期確認では、このSQLiteを使っています。

Node.jsの版を記録し、画面用ファイルをビルドする

以降のコマンドは、learning-appフォルダー内で実行します。
まず、現在選択しているNode.jsの版を.nvmrcへ記録します。
新しいプロジェクトにファイルを作る例なので、既存の.nvmrcがある場合は内容を先に確認してください。

node -p 'process.versions.node' > .nvmrc
cat .nvmrc

検証時のプロジェクトでは、次の1行を記録しました。

24.21.0

.nvmrcがあるフォルダーでnvm useを実行すると、記録した版を選べます。
別の環境でその版が未導入なら、先にnvm installを実行します。

続いて、画面側の依存パッケージを導入し、ビルドします。

nvm use
npm install
npm run build

npm installは、package.jsonに書かれたパッケージをnode_modules/へ導入します。
npm run buildは、そのプロジェクトに登録されたビルド処理を実行するコマンドです。
今回はViteが動き、ブラウザーへ配信するCSS・JavaScriptなどがpublic/build/へ作成されました。
検証時に使われたViteは8.3.4です。

ビルドがエラーで終わっていないことと、次のファイルができていることを確認します。

ls public/build/manifest.json

manifestは、元のCSS・JavaScriptと、ビルド後のファイル名を対応付けるためのファイルです。
ビルド中にフォントなどを取得する設定がある場合は、外部への通信も発生します。

初期テストとデータベースを確認する

起動前に、PHP側の依存要件と初期テスト、データベースの準備状況を確認します。
引き続きlearning-app内で実行してください。

composer validate --strict
composer check-platform-reqs
php artisan test
php artisan migrate:status
確認 判断に使う結果
composer validate --strict Composerの定義にエラーがない
composer check-platform-reqs 導入済みパッケージが要求するPHP本体・拡張の条件を満たす
php artisan test テストが成功し、失敗がない
php artisan migrate:status 初期マイグレーションが実行済みになっている

マイグレーションは、テーブルを作るなど、データベースの構造を準備・変更する処理です。
検証時は標準テスト2件が成功し、users・cache・jobs関連の初期マイグレーション3件も実行済みでした。
この件数は導入時の標準アプリの結果で、独自機能を追加した後の件数とは区別しています。

作成時にマイグレーションが失敗していた場合は、そのエラーを解消してから先へ進みます。
上のコマンドは状態の確認なので、未準備のデータベースを自動的に作り直すものではありません。

開発サーバーを起動し、HTTP応答を確かめる

Laravelの開発サーバーを起動します。
ローカルでの確認用なので、待ち受け先は127.0.0.1にします。

php artisan serve --host=127.0.0.1 --port=8000

このターミナルは起動したままにします。
ブラウザーではhttp://localhost:8000を開いて確認できます。
HTTP応答をコマンドで調べる場合は、別のUbuntuターミナルで次を実行します。

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8000/up

どちらも200と表示されれば、それぞれのURLが正常に応答しています。
/は初期画面、/upはアプリの起動状態を確認するURLです。
検証時は両方が200を返し、初期画面のHTMLにビルド済みファイルの参照が含まれることも確認しました。
ブラウザーの見た目やスマホ実機での表示は、この導入時の確認には含めていません。

確認が終わったら、サーバーを起動したターミナルでCtrl + Cを押して停止します。

まとめ

WSLのUbuntuでNode.js・npmを準備し、ComposerでLaravel 13のプロジェクトを作成しました。
PHP側の依存確認、画面用ファイルのビルド、初期テスト、HTTP応答まで確認すると、ローカル開発を始めるための土台がそろいます。

PHP・ComposerはLaravel本体とPHPライブラリ、Node.js・npm・Viteは画面用ファイルの準備を担います。
コマンドを実行するときは、Ubuntuのターミナルを使っているか、learning-app内に移動しているかも確認してください。

参考: Laravel公式の導入ガイド、Node.jsのリリース情報。