Laravel10→Laravel11を2つのプロジェクトで対応しました
はじめに
ここ最近、Laravel11へのアップグレードを2つのプロジェクトで行いました。
1つは会社でやっているInertiajsを採用したモノリス方式のLaravel、もう一方は個人開発しているプロジェクトのLaravel APIです。
このブログでは、Laravel11へのアップグレードをやっていく上で行ったこと、考えたことなどを書いて共有しておこうとおもいます。
Laravel10 → Laravel11での違いについて
かなり詳しめにまとめられているので詳しくは割愛します。
依存するパッケージのバージョンが引き上げられ、Laravel10でのアプリケーション構造に互換性はあるものの、大きく構造に変化が加えられています。
1つ目のプロジェクトでのアップグレード対応
まずは会社でやったほうです。
背景
冒頭で軽く触れたようにInertiajsを採用してVueフロントエンドへのデータの受け渡しを簡略化させ、チーム全員がフルスタックに開発を行っているプロジェクトになります。
このプロジェクトは開発が始まってから半年近く経過していて、リリースに向けて仕上げている段階です。
アップグレードに際して行ったこと
箇条書きで並べていきます。
- 依存関係のアップグレード
laravel/frameworknunomaduro/collisionlaravel/breezelaravel/cashierinertiajs/inertia-larave
- 依存関係の更新、およびLaravel11での変更による影響を受ける部分の調査
- php拡張の追加（php-bcmath）
- 開発用Dockerfileの更新
- CodeBuild実行用にECRに保存しているDockerイメージの更新
- GitLab CIのワーカー用Dockerfileの更新
- 検証、本番環境などEC2サーバーに拡張を追加
- Laravel Cashierのアップグレードガイドを参考にコードの修正
- Inertia.js v1.0へのアップグレード対応
- （Laravelとは関係がないが）フロントエンド側の依存関係の更新
- Viteのv5へのアップグレード
- ziggyのv2へのアップグレード
以上、かなり大きく変更を加えました。
詰まったところ
Laravel11からはphp8.2以上が必要になったことで、依存関係が内部で利用している依存関係のバージョンと競合しエラーが発生しました。ただ、競合が発生したパッケージは特に本番運用に重要なものではなく、確認したところ現状そこまで使われていないものだったため、削除しました。
Laravel11 のアプリケーション構造に寄せていこうとしたが,,,
当初、Laravel11のアプリケーション構造に寄せていくことを考えましたが、これは少し時間を空けて対応することにしました。公式はLaravel10の構造と互換性があり、構造を寄せることを非推奨としていますが、割と利用頻度が高めなMiddlewareに大きな変更があり、Laravel11を使っているのにLaravel10のドキュメントを見に行くようなことがあると将来的な負債になりかねないと考えています。現在は機能がそろってきていて、テストコードを充実させているので、これらが十分にそろってきたら思い切った再チャレンジをやってみようと思います。
2つ目のプロジェクトでのアップグレード対応
業務が終わって暇なときに作っている、個人開発プロジェクトのうち、バックエンドAPIとして開発しているLaravel10のアプリケーションをLaravel1にアップグレードしました。
アプリケーションの技術的な特徴
軽く1つ目のプロジェクトとの技術的な構成の違いについて述べておきます。
フロントエンドを一切取り扱わないリポジトリで完全にAPI用途として開発しています。
主にコストのメリットを重視してコンテナやEC2へのデプロイではなくLambdaへデプロイしています。そのため、Brefを採用しています。
対応したこと
こちらも箇条書きで書いていきます。
- brefのdockerイメージをphp8.3に更新（Laravel11には8.2で十分）
- 依存パッケージの更新
"laravel/framework": "^11.0""laravel/sanctum": "^4.0""laravel/sanctum": "^4.0"
- 使っていないパッケージを削除（Laravel11へのアップグレードとは関係ない）
- Laravel11のアプリケーション構造に寄せた
brefについて
phpをLambdaに乗せて実行するためのランタイムを提供するツールです。
Lambdaの無料枠を活用して安く済ませたかったのと、サーバレスのサーバーの管理の手間が少ないところに魅力を感じます。
brefは本番環境用のDockerイメージのほかに開発用のDockerイメージを提供していて、それらのphpバージョンを8.3に上げました。（8.2→8.3の変更で影響を受けなかったため）
デプロイはGithub ActionsでServerlessframeworkを使用していますが、こちらのsetup-phpのバージョンを8.3に上げる変更も加えています。
Laravel11のアプリケーション構造に追従
公式が非推奨だとは言っていますが、Laravel11で開発するのにLaravel10での構造でやっているのは個人開発のモチベーションにもなんとなく影響する気がしますし、検証もかねてアプリケーション構造の追従を行いました。
こちらの記事を参考にして変更しています。
まだ開発を始めて3か月程度のプロジェクトで小さく、Laravel11で変更の大きなMiddleware周りをほとんどカスタマイズしていなかったことが影響してか非常に簡単でした。
また、configの中でLaravel11でデフォルトで提供されているもので自分がカスタマイズしているもの以外はすべてLaravel11のものに置き換えました。
テストのおかげでエラーを簡単に把握できた
Featureテストを網羅的に書いていました。
アプリケーション構造を寄せる作業を行った後でsession関連のエラーが報告されており、
php artisan make:session-table
の実行が必要であることに早く気が付くことができました。（ほかにもいくつかのエラーはAPIをたたかずともテストのおかげでつぶせました）
このブログの趣旨とはあまり関係がないですが、テスト書いておくメリットが実感できて非常にいい体験となりました。
最後に
Laravel11へのアップグレードを2つのプロジェクトで行った経験について書かせていただきました。
どちらのプロジェクトにおいてもインフラを含めてサーバーサイド側の構築にかかわっていて割と詳しくなっていたことはこの対応において好影響がありました。
また、テストを書いておくこともフレームワークのアップグレードを簡単にするために効果的でよく書籍とかブログで言われているとうりの効果が実感できたなという感想です。
参考
Discussion