Laravel 8.x リリースノート

バージョニング規約Versioning Scheme

Laravelとファーストパーティパッケージは、セマンティックバージョニングにしたがっています。メジャーなフレームのリリースは、毎年２月にリリースします。マイナーとパッチリリースはより細かく毎週リリースします。マイナーとパッチリリースは、決してブレーキングチェンジを含みませんLaravel and its other first-party packages follow Semantic Versioning[https://semver.org]. Major framework releases are released every year (~February), while minor and patch releases may be released as often as every week. Minor and patch releases should never contain breaking changes.

皆さんのアプリケーションやパッケージからLaravelフレームワークかコンポーネントを参照する場合は、Laravelのメジャーリリースはブレーキングチェンジを含まないわけですから、^8.0のようにバージョンを常に指定してください。しかし、新しいメジャーリリースへ１日以内でアップデートできるように、私たちは常に努力しています。When referencing the Laravel framework or its components from your application or package, you should always use a version constraint such as ^8.0, since major releases of Laravel do include breaking changes. However, we strive to always ensure you may update to a new major release in one day or less.

例外Exceptions

名前付き引数Named Arguments

現時点では、PHPの名前付き引数機能はLaravelの後方互換性ガイドラインでカバーしていません。Laravelのコードベースを改善するため必要に応じ、私達は機能パラメータの名前を変更することを選択するでしょう。したがって、パラメータ名が将来変更される可能性があることを理解して、Laravelのメソッド呼び出しに名前付き引数を使用することは、慎重に行う必要があります。At this time, PHP's named arguments[https://www.php.net/manual/en/functions.arguments.php#functions.named-arguments] functionality are not covered by Laravel's backwards compatibility guidelines. We may choose to rename function parameters when necessary in order to improve the Laravel codebase. Therefore, using named arguments when calling Laravel methods should be done cautiously and with the understanding that the parameter names may change in the future.

サポートポリシーSupport Policy

Laravelのすべてのリリースは、バグフィックスは１８ヶ月、セキュリティフィックスは２年です。Lumenのようなその他の追加ライブラリでは、最新リリースのみでバグフィックスを受け付けています。また、Laravelがサポートするデータベースのサポートについても確認してください。For all Laravel releases, bug fixes are provided for 18 months and security fixes are provided for 2 years. For all additional libraries, including Lumen, only the latest release receives bug fixes. In addition, please review the database versions supported by Laravel[/docs/{{version}}/database#introduction].

(*) 対応PHPバージョン(*) Supported PHP versions

Laravel8Laravel 8

Laravel8は、Laravel7.xで行われた向上に加え、以降の変更で構成されています。Laravel Jetstreamの導入、モデルファクトリクラスの導入、マイグレーションの圧縮の導入、ジョブバッチの導入、レート制限の向上、キューの向上、ダイナミックBladeコンポーネントの導入、Tailwindペジネーションビューの導入、時間テストヘルパの導入、artisan serveの向上、イベントリスナの向上、ならびに多くのバグフィックスとユーザービリティの向上ですLaravel 8 continues the improvements made in Laravel 7.x by introducing Laravel Jetstream, model factory classes, migration squashing, job batching, improved rate limiting, queue improvements, dynamic Blade components, Tailwind pagination views, time testing helpers, improvements to artisan serve, event listener improvements, and a variety of other bug fixes and usability improvements.

Laravel JetstreamLaravel Jetstream

Laravel Jettreamは、Taylor Otwellにより書かれました。Laravel Jetstream was written by Taylor Otwell[https://github.com/taylorotwell].

Laravel Jetstream（和訳）（和訳）は、Laravelのために美しくデザインされたアプリケーションのスカフォールドです。Jetstreamは、ログイン、ユーザー登録、メール認証、二要素認証、セッション管理、Laravel SanctumによるのAPIサポート、およびオプションのチーム管理など、次のプロジェクトのための完璧なスタートポイントを提供します。Laravel Jetstreamは、以前のLaravelバージョンで利用可能であったレガシーな認証UIのスカフォールドに代わるものであり、改善されています。Laravel Jetstream[https://jetstream.laravel.com] is a beautifully designed application scaffolding for Laravel. Jetstream provides the perfect starting point for your next project and includes login, registration, email verification, two-factor authentication, session management, API support via Laravel Sanctum, and optional team management. Laravel Jetstream replaces and improves upon the legacy authentication UI scaffolding available for previous versions of Laravel.

JetstreamはTailwind CSSを使用してデザインされており、LivewireかInertiaのどちらかのスカフォールドを選択できます。Jetstream is designed using Tailwind CSS[https://tailwindcss.com] and offers your choice of Livewire[https://laravel-livewire.com] or Inertia[https://inertiajs.com] scaffolding.

モデルディレクトリModels Directory

コミュニティからの圧倒的な要望により、デフォルトのLaravelアプリケーションのスケルトンにapp/Modelsディレクトリが含まれるようになりました。Eloquentモデルの新しいホームをお楽しみください。関連するジェネレータコマンドはすべて、モデルがapp/Modelsディレクトリ内に存在する仮定のもとに更新されました。ディレクトリが存在しない場合、フレームワークはモデルがappディレクトリ内にあると仮定します。By overwhelming community demand, the default Laravel application skeleton now contains an app/Models directory. We hope you enjoy this new home for your Eloquent models! All relevant generator commands have been updated to assume models exist within the app/Models directory if it exists. If the directory does not exist, the framework will assume your models should be placed within the app directory.

モデルファクトリクラスModel Factory Classes

モデルファクトリクラスは、Taylor Otwellが貢献しました。Model factory classes were contributed by Taylor Otwell[https://github.com/taylorotwell].

Eloquentモデルファクトリは、クラスベースのファクトリとして完全に書き直され、ファーストクラスのリレーションシップをサポートするように改良されました。たとえば、Laravelに含まれるUserFactoryは次のように書かれています。Eloquent model factories[/docs/{{version}}/database-testing#defining-model-factories] have been entirely re-written as class based factories and improved to have first-class relationship support. For example, the UserFactory included with Laravel is written like so:

<?php

namespace Database\Factories;

use App\Models\User;
use Illuminate\Database\Eloquent\Factories\Factory;
use Illuminate\Support\Str;

class UserFactory extends Factory
{
    /**
     * モデルに対応したファクトリの名前
     *
     * @var string
     */
    protected $model = User::class;

    /**
     * モデルのデフォルト状態
     *
     * @return array
     */
    public function definition()
    {
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'email_verified_at' => now(),
            'password' => '$2y$10$92IXUNpkjO0rOQ5byMi.Ye4oKoEa3Ro9llC/.og/at2.uheWG/igi', // password
            'remember_token' => Str::random(10),
        ];
    }
}

生成されたモデルで利用できる新しいHasFactoryトレイトのおかげで、モデルファクトリを以下のように利用できます。Thanks to the new HasFactory trait available on generated models, the model factory may be used like so:

use App\Models\User;

User::factory()->count(50)->create();

モデルファクトリは現在、シンプルな PHP クラスになったため、状態遷移はクラスメソッドとして記述できます。さらに、必要に応じて他のヘルパクラスをEloquentモデルファクトリに追加できます。Since model factories are now simple PHP classes, state transformations may be written as class methods. In addition, you may add any other helper classes to your Eloquent model factory as needed.

たとえばUserモデルは、デフォルトの属性値の一つを変更するsuspended状態を持っているとしましょう。ベースファクトリのstateメソッドを使い、状態遷移を定義できます。ステートメソッドには好きな名前を付けてください。つまるところ、これは典型的なPHPのメソッドです。For example, your User model might have a suspended state that modifies one of its default attribute values. You may define your state transformations using the base factory's state method. You may name your state method anything you like. After all, it's just a typical PHP method:

/**
 * そのユーザーが利用停止であることを表す
 *
 * @return \Illuminate\Database\Eloquent\Factories\Factory
 */
public function suspended()
{
    return $this->state([
        'account_status' => 'suspended',
    ]);
}

状態遷移メソッドを定義したら、以下のように使用します。After defining the state transformation method, we may use it like so:

use App\Models\User;

User::factory()->count(5)->suspended()->create();

前述のとおり、Laravel8のモデルファクトリはリレーションのファーストクラスをサポートしています。ですから、Userモデルにpostsリレーションがあると仮定し、以下のコードを実行して、3つのポストを持つユーザーを生成できます。As mentioned, Laravel 8's model factories contain first class support for relationships. So, assuming our User model has a posts relationship method, we may simply run the following code to generate a user with three posts:

$users = User::factory()
            ->hasPosts(3, [
                'published' => false,
            ])
            ->create();

簡単にアップグレードできるよう、laravel/legacy-factoriesパッケージがリリースされ、Laravel8.x内のモデルファクトリの以前の反復をサポートしています。To ease the upgrade process, the laravel/legacy-factories[https://github.com/laravel/legacy-factories] package has been released to provide support for the previous iteration of model factories within Laravel 8.x.

リライトしたLaravelのファクトリは、皆さんに気に入ってもらえるような多くの機能が含まれています。モデルファクトリの詳細は、データベーステストのドキュメントを参照してください。Laravel's re-written factories contain many more features that we think you will love. To learn more about model factories, please consult the database testing documentation[/docs/{{version}}/database-testing#defining-model-factories].

マイグレーションの圧縮Migration Squashing

マイグレーションの圧縮は、Taylor Otwellが貢献しました.Migration squashing was contributed by Taylor Otwell[https://github.com/taylorotwell].

アプリケーションを構築するにつれ、時間の経過とともに段々多くのマイグレーションが溜まっていく可能性があります。これにより、マイグレーションディレクトリが数百ものマイグレーションで肥大化するかもしれません。MySQLもしくはPostgreSQLを使用している場合は、マイグレーションを１つのＳＱＬファイルに「圧縮」できます。利用するには、schema：dumpコマンドを実行します：As you build your application, you may accumulate more and more migrations over time. This can lead to your migration directory becoming bloated with potentially hundreds of migrations. If you're using MySQL or PostgreSQL, you may now "squash" your migrations into a single SQL file. To get started, execute the schema:dump command:

php artisan schema:dump

// 現在のデータベーススキーマを圧縮し、既存のマイグレーションを削除する
php artisan schema:dump --prune

このコマンドを実行すると、Laravelは「スキーマ」ファイルをdatabase/schemaディレクトリに書き込みます。これにより、データベースをマイグレートしようとするときに他のマイグレーションは実行されず、Laravelは最初にスキーマファイルのＳＱＬを実行します。スキーマファイルのコマンドを実行した後、Laravelはスキーマダンプに圧縮されていない残りのマイグレーションを実行します。When you execute this command, Laravel will write a "schema" file to your database/schema directory. Now, when you attempt to migrate your database and no other migrations have been executed, Laravel will execute the schema file's SQL first. After executing the schema file's commands, Laravel will execute any remaining migrations that were not part of the schema dump.

ジョブバッチJob Batching

ジョブバッチは、Taylor OtwellとMohamed Saidが貢献しました。.Job batching was contributed by Taylor Otwell[https://github.com/taylorotwell] & Mohamed Said[https://github.com/themsaid].

Laravelのジョブバッチ処理機能を使用すると、バッチジョブを簡単に実行し、バッチの実行が完了したときに何らかのアクションを実行できます。Laravel's job batching feature allows you to easily execute a batch of jobs and then perform some action when the batch of jobs has completed executing.

Busファサードの新しいbatchメソッドを使用して、バッチジョブをディスパッチできます。もちろん、バッチ処理は終了コールバックと合わせて使用すると、とくに便利です。そのため、then、 catch、finallyメソッドにより、バッチの終了コールバックが定義できます。こうしたコールバックはそれぞれ呼び出し時に、Illuminate\Bus\Batchインスタンスを引数に受け取ります。The new batch method of the Bus facade may be used to dispatch a batch of jobs. Of course, batching is primarily useful when combined with completion callbacks. So, you may use the then, catch, and finally methods to define completion callbacks for the batch. Each of these callbacks will receive an Illuminate\Bus\Batch instance when they are invoked:

use App\Jobs\ProcessPodcast;
use App\Podcast;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
use Throwable;

$batch = Bus::batch([
    new ProcessPodcast(Podcast::find(1)),
    new ProcessPodcast(Podcast::find(2)),
    new ProcessPodcast(Podcast::find(3)),
    new ProcessPodcast(Podcast::find(4)),
    new ProcessPodcast(Podcast::find(5)),
])->then(function (Batch $batch) {
    // 全ジョブが実行成功して終了した
})->catch(function (Batch $batch, Throwable $e) {
    // 最初にバッチジョブの失敗が検出された
})->finally(function (Batch $batch) {
    // バッチの実行が終了した
})->dispatch();

return $batch->id;

バッチジョブの詳細は、キューのドキュメントをお読みください。To learn more about job batching, please consult the queue documentation[/docs/{{version}}/queues#job-batching].

レート制限の向上Improved Rate Limiting

レート制限の向上は、Taylor Otwellが貢献しました.Rate limiting improvements were contributed by Taylor Otwell[https://github.com/taylorotwell].

Laravelのリクエストレート制限機能は、以前のリリースのthrottleミドルウェアAPIとの下位互換性を維持しながら、柔軟性とパワーが強化されています。Laravel's request rate limiter feature has been augmented with more flexibility and power, while still maintaining backwards compatibility with previous release's throttle middleware API.

レート制限は、RateLimiterファサードのforメソッドを使用して定義します。forメソッドは、レート制限名と、このレート制限が割り当てられているルートへ適用する必要がある制限設定を返すクロージャを引数に取ります。Rate limiters are defined using the RateLimiter facade's for method. The for method accepts a rate limiter name and a closure that returns the limit configuration that should apply to routes that are assigned this rate limiter:

use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

RateLimiter::for('global', function (Request $request) {
    return Limit::perMinute(1000);
});

レート制限コールバックは、受信HTTPリクエストインスタンスを引数に受けるため、受信リクエストまたは認証済みユーザーに基づいた適切なレート制限を動的に構築できます。Since rate limiter callbacks receive the incoming HTTP request instance, you may build the appropriate rate limit dynamically based on the incoming request or authenticated user:

RateLimiter::for('uploads', function (Request $request) {
    return $request->user()->vipCustomer()
                ? Limit::none()
                : Limit::perMinute(100);
});

レート制限を任意の値で分割したい場合があります。たとえば、ユーザーが特定のルートにIPアドレスに対し1分あたり１００回アクセスすることを許可したい場合です。それには、レート制限を作成するときにbyメソッドを使用します。Sometimes you may wish to segment rate limits by some arbitrary value. For example, you may wish to allow users to access a given route 100 times per minute per IP address. To accomplish this, you may use the by method when building your rate limit:

RateLimiter::for('uploads', function (Request $request) {
    return $request->user()->vipCustomer()
                ? Limit::none()
                : Limit::perMinute(100)->by($request->ip());
});

レート制限は、throttle ミドルウェアを使用してルートまたはルートグループに付加します。スロットルミドルウェアの引数は、ルートに割り付けるレート制限の名前です。Rate limiters may be attached to routes or route groups using the throttle middleware[/docs/{{version}}/middleware]. The throttle middleware accepts the name of the rate limiter you wish to assign to the route:

Route::middleware(['throttle:uploads'])->group(function () {
    Route::post('/audio', function () {
        //
    });

    Route::post('/video', function () {
        //
    });
});

レート制限の詳細は、ルーティングドキュメントを参照してください。To learn more about rate limiting, please consult the routing documentation[/docs/{{version}}/routing#rate-limiting].

メンテナンスモードの向上Improved Maintenance Mode

メンテナンスモードの向上はSpatieからインスピレーションを受け、Taylor Otwellが貢献しました.Maintenance mode improvements were contributed by Taylor Otwell[https://github.com/taylorotwell] with inspiration from Spatie[https://spatie.be].

以前のLaravelリリースではアプリケーションへのアクセスを許可するIPアドレスの「許可リスト」を使用して、php artisan downメンテナンスモード機能をバイパスできました。この機能は、より単純な「秘密」/トークンによる解決法導入により削除しました。In previous releases of Laravel, the php artisan down maintenance mode feature may be bypassed using an "allow list" of IP addresses that were allowed to access the application. This feature has been removed in favor of a simpler "secret" / token solution.

メンテナンスモードの間、secretオプションを使用してメンテナンスモードのバイパストークンを指定します。While in maintenance mode, you may use the secret option to specify a maintenance mode bypass token:

php artisan down --secret="1630542a-246b-4b66-afa1-dd72a4c43515"

アプリケーションをメンテナンスモードにした後、このトークンに一致するアプリケーションURLへ移行すると、LaravelはブラウザへメンテナンスモードのバイパスCookieを発行します。After placing the application in maintenance mode, you may navigate to the application URL matching this token and Laravel will issue a maintenance mode bypass cookie to your browser:

https://example.com/1630542a-246b-4b66-afa1-dd72a4c43515

この隠しルートにアクセスすると、アプリケーションの/ルートへリダイレクトします。ブラウザにクッキーが発行されれば、メンテナンスモードではないときと同じように、アプリケーションを通常通り閲覧できます。When accessing this hidden route, you will then be redirected to the / route of the application. Once the cookie has been issued to your browser, you will be able to browse the application normally as if it was not in maintenance mode.

メンテナンスモードビューの事前レンダリングPre-Rendering The Maintenance Mode View

デプロイ時、php artisan downコマンドを使用する場合、Composerの依存関係またはその他の基礎コンポーネントの更新中にユーザーがアプリケーションへアクセスすることで、エラーが発生する可能性があります。これはアプリケーションがメンテナンスモードであることを確認し、テンプレートエンジンを使用してメンテナンスモードビューを表示するためには、Laravelフレームワークの重要な部分が起動されている必要があるためです。If you utilize the php artisan down command during deployment, your users may still occasionally encounter errors if they access the application while your Composer dependencies or other infrastructure components are updating. This occurs because a significant part of the Laravel framework must boot in order to determine your application is in maintenance mode and render the maintenance mode view using the templating engine.

このためLaravelは、リクエストサイクルの最初に返されるメンテナンスモードビューを事前レンダリングできるようになりました。このビューは、アプリケーションの依存パッケージが読み込まれる前にレンダリングされます。downコマンドの renderオプションを使用して、選択したテンプレートを事前レンダーできます：For this reason, Laravel now allows you to pre-render a maintenance mode view that will be returned at the very beginning of the request cycle. This view is rendered before any of your application's dependencies have loaded. You may pre-render a template of your choice using the down command's render option:

php artisan down --render="errors::503"

ディスパッチクロージャとcatchチェーンClosure Dispatch / Chain catch

Catchの向上はMohamed Saidが貢献しました.Catch improvements were contributed by Mohamed Said[https://github.com/themsaid].

新しいcatchメソッドを使用して、キューに投入されたクロージャが正常に完了しなかった場合に、キューの設定済みの再試行回数をすべて使い果たしたときに実行する、クロージャを引数へ渡せるようになりました。Using the new catch method, you may now provide a closure that should be executed if a queued closure fails to complete successfully after exhausting all of your queue's configured retry attempts:

use Throwable;

dispatch(function () use ($podcast) {
    $podcast->publish();
})->catch(function (Throwable $e) {
    // このジョブは失敗した
});

動的BladeコンポーネントDynamic Blade Components

動的Bladeコンポーネントは、Taylor Otwellが貢献しました.Dynamic Blade components were contributed by Taylor Otwell[https://github.com/taylorotwell].

コンポーネントをレンダーする必要があるが、実行時までどれをレンダーするかわからない場合があります。この状況では、Laravelに組み込まれているdynamic-componentコンポーネントを使用して、ランタイム値や変数に基づきコンポーネントをレンダリングできます。Sometimes you may need to render a component but not know which component should be rendered until runtime. In this situation, you may now use Laravel's built-in dynamic-component component to render the component based on a runtime value or variable:

<x-dynamic-component :component="$componentName" class="mt-4" />

Bladeコンポーネントの詳細は、Bladeのドキュメントをご覧ください。To learn more about Blade components, please consult the Blade documentation[/docs/{{version}}/blade#components].

イベントリスナの向上Event Listener Improvements

イベントリスナの向上は、Taylor OtwellTaylor Otwellが貢献しました.Event listener improvements were contributed by Taylor Otwell[https://github.com/taylorotwell].

クロージャベースのイベントリスナは、クロージャをEvent::listenメソッドへ渡すだけで登録できるようになりました。Laravelはクロージャを調べ、リスナが処理するイベントのタイプを判別します。Closure based event listeners may now be registered by only passing the closure to the Event::listen method. Laravel will inspect the closure to determine which type of event the listener handles:

use App\Events\PodcastProcessed;
use Illuminate\Support\Facades\Event;

Event::listen(function (PodcastProcessed $event) {
    //
});

さらに、クロージャベースのイベントリスナは、Illuminate\Events\queueable関数を使用し、キュー可能としてマークできるようになりました。In addition, closure based event listeners may now be marked as queueable using the Illuminate\Events\queueable function:

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;

Event::listen(queueable(function (PodcastProcessed $event) {
    //
}));

キュー投入するジョブと同様に、キューリスナの実行をカスタマイズするonConnection、onQueue、delayメソッドが使用できます。Like queued jobs, you may use the onConnection, onQueue, and delay methods to customize the execution of the queued listener:

Event::listen(queueable(function (PodcastProcessed $event) {
    //
})->onConnection('redis')->onQueue('podcasts')->delay(now()->addSeconds(10)));

P匿名のキューに投入したリスナの失敗を処理したい場合は、queueableリスナを定義するときにcatchメソッドにクロージャを指定できます。If you would like to handle anonymous queued listener failures, you may provide a closure to the catch method while defining the queueable listener:

use App\Events\PodcastProcessed;
use function Illuminate\Events\queueable;
use Illuminate\Support\Facades\Event;
use Throwable;

Event::listen(queueable(function (PodcastProcessed $event) {
    //
})->catch(function (PodcastProcessed $event, Throwable $e) {
    // キュー済みリスナは失敗した
}));

時間テストのヘルパTime Testing Helpers

時間テストのヘルパはRuby on Railsからインスピレーションを受け、Taylor Otwellが貢献しました.Time testing helpers were contributed by Taylor Otwell[https://github.com/taylorotwell] with inspiration from Ruby on Rails.

テスト時、nowやIlluminate\SupportCarbon::now()のようなヘルパが返す時間を変更する必要が起き得ます。Laravelの機能テストクラスのベースには、現時刻を操作できるヘルパを用意しています。When testing, you may occasionally need to modify the time returned by helpers such as now or Illuminate\Support\Carbon::now(). Laravel's base feature test class now includes helpers that allow you to manipulate the current time:

public function testTimeCanBeManipulated()
{
    // 未来へ時間移動する
    $this->travel(5)->milliseconds();
    $this->travel(5)->seconds();
    $this->travel(5)->minutes();
    $this->travel(5)->hours();
    $this->travel(5)->days();
    $this->travel(5)->weeks();
    $this->travel(5)->years();

    // 過去へ時間移動する
    $this->travel(-5)->hours();

    // 特定の時刻へ時間移動する
    $this->travelTo(now()->subHours(6));

    // 現在時刻へ戻る
    $this->travelBack();
}

Artisan serveの向上Artisan serve Improvements

Artisan serveの向上は、Taylor Otwellが貢献しました。.Artisan serve improvements were contributed by Taylor Otwell[https://github.com/taylorotwell].

Artisan serveコマンドは、ローカルの.envファイル内で環境変数の変更が検出されたとき、自動でリロードするように改善されました。以前は、コマンドを手動で停止して再起動しなければなりませんでした。The Artisan serve command has been improved with automatic reloading when environment variable changes are detected within your local .env file. Previously, the command had to be manually stopped and restarted.

TailwindペジネーションビューTailwind Pagination Views

LaravelのペジネータはデフォルトでTailwind CSSフレームワークを使用するように変更しました。Tailwind CSSは高度にカスタマイズできる低レベルなCSSフレームワークで、オーバーライドのために戦う必要のある煩わしい意見的なスタイルを使用せずに、お誂え向きのデザインを構築するために必要なすべてのビルディングブロックを提供してくれます。もちろん、Bootstrap３と４のビューも利用可能です。The Laravel paginator has been updated to use the Tailwind CSS[https://tailwindcss.com] framework by default. Tailwind CSS is a highly customizable, low-level CSS framework that gives you all of the building blocks you need to build bespoke designs without any annoying opinionated styles you have to fight to override. Of course, Bootstrap 3 and 4 views remain available as well.

ルートの名前空間の向上Routing Namespace Updates

以前のリリースのLaravelでは、RouteServiceProviderは$namespaceプロパティを持っていました。このプロパティの値は、コントローラのルート定義やactionヘルパ／URL::actionメソッドの呼び出しに、自動でプレフィックスを付加していました。Laravel8.xでこのプロパティはデフォルトでnullです。これは、Laravelは自動的に名前空間のプレフィクスを付けなくなったことを意味します。そのため、新しいLaravel8.xアプリケーションでは、コントローラルートの定義は標準的なPHPで呼び出し可能な構文を使って定義する必要があります。In previous releases of Laravel, the RouteServiceProvider contained a $namespace property. This property's value would automatically be prefixed onto controller route definitions and calls to the action helper / URL::action method. In Laravel 8.x, this property is null by default. This means that no automatic namespace prefixing will be done by Laravel. Therefore, in new Laravel 8.x applications, controller route definitions should be defined using standard PHP callable syntax:

use App\Http\Controllers\UserController;

Route::get('/users', [UserController::class, 'index']);

action関係のメソッドの呼び出しも、同じく呼び出し可能な記法を使ってください。Calls to the action related methods should use the same callable syntax:

action([UserController::class, 'index']);

return Redirect::action([UserController::class, 'index']);

Laravel7.xスタイルのコントローラルートのプレフィックスが好みならば、アプリケーションのRouteServiceProviderの中に、$namespaceプレフィックスをただ追加するだけです。If you prefer Laravel 7.x style controller route prefixing, you may simply add the $namespace property into your application's RouteServiceProvider.

Note: note この変更は新しいLaravel8.xアプリケーションでのみ影響します。Laravel7xからアップグレードしたアプリケーションは、RouteServiceProviderに$namespaceプロパティを持ったままでしょう。{note} This change only affects new Laravel 8.x applications. Applications upgrading from Laravel 7.x will still have the $namespace property in their RouteServiceProvider.