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