Laravel 5.8 リリースノート

バージョニング規約Versioning Scheme

Laravelのバージョニングは、「パラダイム.メジャー・マイナー」の規約を維持しています。メジャーフレームワークリリースは、１月と６月の半年ごとにリリースします。一方、マイナーリリースは毎週のように、頻繁にリリースされます。マイナーリリースは、ブレーキングチェンジを絶対に含めません。Laravel's versioning scheme maintains the following convention: paradigm.major.minor. Major framework releases are released every six months (February and August), while minor releases may be released as often as every week. Minor releases should never contain breaking changes.

アプリケーションやパッケージで、Laravelフレームワークやコンポーネントを利用する場合、常に5.8.*のようにバージョンを指定してください。理由は上記の通り、Laravelのメジャーリリースは、ブレーキングチェンジを含んでいるからです。新しいメジャーリリースへの更新は、一日かからない程度になるように努力しています。When referencing the Laravel framework or its components from your application or package, you should always use a version constraint such as 5.8.*, 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.

パラダイムシフトリリースは数年空けています。これはフレームワークの構造と規約に重要な変更が起きたことを表します。現在、パラダイムシフトリリースは開発されていません。Paradigm shifting releases are separated by many years and represent fundamental shifts in the framework's architecture and conventions. Currently, there is no paradigm shifting release under development.

サポートポリシーSupport Policy

Laravel5.5のようなLTSリリースでは、バグフィックスは２年間、セキュリティフィックスは３年間提供します。これらのリリースは長期間に渡るサポートとメンテナンスを提供します。 一般的なリリースでは、バグフィックスは６ヶ月、セキュリティフィックスは１年です。Lumenのようなその他の追加ライブラリでは、最新リリースのみでバグフィックスを受け付けています。For LTS releases, such as Laravel 5.5, bug fixes are provided for 2 years and security fixes are provided for 3 years. These releases provide the longest window of support and maintenance. For general releases, bug fixes are provided for 6 months and security fixes are provided for 1 year. For all additional libraries, including Lumen, only the latest release receives bug fixes.

バージョンVersion	リリースRelease	バグフィックス期限Bug Fixes Until	セキュリティフィックス期限Security Fixes Until
5.05.0	２０１５年２月４日February 4th, 2015	２０１５年８月４日August 4th, 2015	２０１６年２月４日February 4th, 2016
5.1 (LTS)5.1 (LTS)	２０１５年５月９日June 9th, 2015	２０１７年６月９日June 9th, 2017	２０１８年６月９日June 9th, 2018
5.25.2	２０１５年１２月２１日December 21st, 2015	２０１６年６月２１日June 21st, 2016	２０１６年１２月２１日December 21st, 2016
5.35.3	２０１６年８月２３日August 23rd, 2016	２０１７年２月２３日February 23rd, 2017	２０１７年８月２３日August 23rd, 2017
5.45.4	２０１７年１月２４日January 24th, 2017	２０１７年７月２４日July 24th, 2017	２０１８年１月２４日January 24th, 2018
5.5 (LTS)5.5 (LTS)	２０１７年８月３０日August 30th, 2017	２０１９年８月３０日August 30th, 2019	２０２０年８月３０日August 30th, 2020
5.65.6	２０１８年２月７日February 7th, 2018	２０１８年８月７日August 7th, 2018	２０１９年２月７日February 7th, 2019
5.75.7	２０１８年９月４日September 4th, 2018	２０１９年３月４日March 4th, 2019	２０１９年９月４日September 4th, 2019
5.85.8	２０１９年２月２６日February 26th, 2019	２０１９年８月２６日August 26th, 2019	２０２０年２月２６日February 26th, 2020

Laravel5.8Laravel 5.8

Laravel5.8は5.7で行われた改善を継続しています。今回のバージョンでは、"HasOneThrough" Eloquentリレーションの導入、規約ベースの認可ポリシーの自動登録の導入、DynamoDBキャッシュとセッションドライバーのサポート、メールバリデーションの改良、スケジューラーのタイムゾーン設定のサポート、ブロードキャストチャンネルに対する複数認可ガード指定のサポート、PSR-16キャッシュドライバー準拠、artisan serveコマンドの向上、PHPUnit8.0のサポート、Carbon2.0サポート、Pheanstalk4.0サポートと、様々なバグフィックス並びに不安定の改善が行われました。Laravel 5.8 continues the improvements made in Laravel 5.7 by introducing has-one-through Eloquent relationships, improved email validation, convention based automatic registration of authorization policies, DynamoDB cache and session drivers, improved scheduler timezone configuration, support for assigning multiple authentication guards to broadcast channels, PSR-16 cache driver compliance, improvements to the artisan serve command, PHPUnit 8.0 support, Carbon 2.0 support, Pheanstalk 4.0 support, and a variety of other bug fixes and usability improvements.

Eloquent HasOneThroughリレーションEloquent HasOneThrough Relationship

EloquentにhasOneThroughリレーションタイプのサポートを提供始めました。例として、サプライヤ（Supplier）モデルがアカウント（Account）モデルを一つ持ち（hasOne）、アカウントモデルもアカウント履歴（AccountHistory）モデルを一つ持っているとイメージしてください。サプライヤのアカウント履歴にアクセスするために、アカウントモデルを経由し、hasOneThroughリレーションが利用できます。Eloquent now provides support for the hasOneThrough relationship type. For example, imagine a Supplier model hasOne Account model, and an Account model has one AccountHistory model. You may use a hasOneThrough relationship to access a supplier's account history through the account model:

/**
 * サプライヤに対するアカウント履歴を取得
 */
public function accountHistory()
{
    return $this->hasOneThrough(AccountHistory::class, Account::class);
}

モデルポリシーの自動検出Auto-Discovery Of Model Policies

Laravel5.7を使う場合は、モデルに対応する認可ポリシーをアプリケーションのAuthServiceProviderで明示的に登録する必要がありました。When using Laravel 5.7, each model's corresponding authorization policy[/docs/{{version}}/authorization#creating-policies] needed to be explicitly registered in your application's AuthServiceProvider:

/**
 * アプリケーションに対するポリシーマッピング
 *
 * @var array
 */
protected $policies = [
    'App\User' => 'App\Policies\UserPolicy',
];

Laravel5.8ではモデルポリシーの自動検出が導入され、モデルとポリシーの標準命名規則に従っているポリシーを自動的にLaravelは見つけます。具体的にはモデルが含まれているディレクトリの下に存在する、Policiesディレクトリ中のポリシーです。たとえば、モデルがappディレクトリ下にあれば、ポリシーはapp/Policiesディレクトリへ置く必要があります。さらに、ポリシーの名前は対応するモデルの名前へ、Policyサフィックスを付けたものにする必要があります。ですから、Userモデルに対応させるには、UserPolicyクラスと命名します。Laravel 5.8 introduces auto-discovery of model policies as long as the model and policy follow standard Laravel naming conventions. Specifically, the policies must be in a Policies directory below the directory that contains the models. So, for example, the models may be placed in the app directory while the policies may be placed in the app/Policies directory. In addition, the policy name must match the model name and have a Policy suffix. So, a User model would correspond to a UserPolicy class.

独自のポリシー発見ロジックを利用したい場合、Gate::guessPolicyNamesUsingメソッドでカスタムコールバックを登録します。通常このメソッドは、AuthServiceProviderから呼び出すべきでしょう。If you would like to provide your own policy discovery logic, you may register a custom callback using the Gate::guessPolicyNamesUsing method. Typically, this method should be called from your application's AuthServiceProvider:

use Illuminate\Support\Facades\Gate;

Gate::guessPolicyNamesUsing(function ($modelClass) {
    // ポリシークラス名を返す…
});

Note: note AuthServiceProvider中で明確にマップされたポリシーは、自動検出される可能性のあるポリシーよりも優先的に扱われます。{note} Any policies that are explicitly mapped in your AuthServiceProvider will take precedence over any potential auto-discovered policies.

PSR-16キャッシュ準拠PSR-16 Cache Compliance

より細かい時間でアイテムの保存時間を扱えるように、そしてPSR-16キャッシュ基準に準拠するために、キャッシュの保存時間は分から秒単位になりました。Illuminate\Cache\Repositoryクラスとこれを拡張したクラスのput、putMany、add、remember、setDefaultCacheTimeメソッド、並びに各キャッシュ保存のputメソッドはこの動作変更へ更新されました。詳細は、関係するPRをご覧ください。In order to allow a more granular expiration time when storing items and provide compliance with the PSR-16 caching standard, the cache item time-to-live has changed from minutes to seconds. The put, putMany, add, remember and setDefaultCacheTime methods of the Illuminate\Cache\Repository class and its extended classes, as well as the put method of each cache store were updated with this changed behavior. See the related PR[https://github.com/laravel/framework/pull/27276] for more info.

前述のメソッドに整数値を渡している場合、キャッシュにアイテムを残したい時間が秒数になったことに留意し、コードを変更してください。言い換えれば、アイテムの期限がいつ切れるかを表すDateTimeインスタンスを渡したほうが良いでしょう。If you are passing an integer to any of these methods, you should update your code to ensure you are now passing the number of seconds you wish the item to remain in the cache. Alternatively, you may pass a DateTime instance indicating when the item should expire:

// Laravel5.7：30分アイテムは保存される
Cache::put('foo', 'bar', 30);

// Laravel5.8：30秒アイテムは保存される
Cache::put('foo', 'bar', 30);

// Laravel5.7と5.8：30秒アイテムは保存される
Cache::put('foo', 'bar', now()->addSeconds(30));

複数のブロードキャスト認可ガードMultiple Broadcast Authentication Guards

Laravelの以前のリリースでは、プライベートとプレゼンス・ブロードキャスト・チャンネルは、アプリケーションのデフォルト認証ガードにより、ユーザーを認証していました。Laravel5.8からは、受信したリクエストを認可する複数のガードを指定できるようになりました。In previous releases of Laravel, private and presence broadcast channels authenticated the user via your application's default authentication guard. Beginning in Laravel 5.8, you may now assign multiple guards that should authenticate the incoming request:

Broadcast::channel('channel', function() {
    // ...
}, ['guards' => ['web', 'admin']])

tokenガードとトークンのハッシュToken Guard Token Hashing

Laravelのtokenガードは基本的なAPI認証を提供していますが、SHA-256ハッシュの文字列APIトークンをサポートするようになりました。これにより、保存された平文トークンよりもセキュリティが向上しました。ハッシュ済みトークンの詳細は、API認証のドキュメントで確認してください。Laravel's token guard, which provides basic API authentication, now supports storing API tokens as SHA-256 hashes. This provides improved security over storing plain-text tokens. To learn more about hashed tokens, please review the full API authentication documentation[/docs/{{version}}/api-authentication].

Note: Laravelではシンプルなトークンベースの認証ガードを提供していますが、API認証を提供する堅牢なプロダクションアプリケーションでは、Laravel Passportの使用をAPI認証ではおすすめします。Note: While Laravel ships with a simple, token based authentication guard, we strongly recommend you consider using Laravel Passport[/docs/{{version}}/passport] for robust, production applications that offer API authentication.

メールバリデーションの向上Improved Email Validation

Laravel5.8では、SwiftMailerが使用しているegulias/email-validatorパッケージを採用し、バリデータのメールバリデーションを向上しました。Laravelの以前のメールバリデーションロジックでは、example@bär.seなど有効なEメールアドレスを時に無効と判断していました。Laravel 5.8 introduces improvements to the validator's underlying email validation logic by adopting the egulias/email-validator package utilized by SwiftMailer. Laravel's previous email validation logic occasionally considered valid emails, such as example@bär.se, to be invalid.

スケジューラのデフォルトタイムゾーンDefault Scheduler Timezone

Laravelではtimezoneメソッドを使うことで、一つのスケジュールタスクのタイムゾーンをカスタマイズできました。Laravel allows you to customize the timezone of a scheduled task using the timezone method:

$schedule->command('inspire')
         ->hourly()
         ->timezone('America/Chicago');

しかしながら、スケジュール済みの全タスクに対して、同じタイムゾーンを指定する場合、繰り返しの手間がかかっていました。そのため、app/Console/Kernel.phpファイルでscheduleTimezoneメソッドを定義できるようになりました。このメソッドは、スケジュールタスクに対し指定する、デフォルトのタイムゾーンを返します。However, this can become cumbersome and repetitive if you are specifying the same timezone for all of your scheduled tasks. For that reason, you may now define a scheduleTimezone method in your app/Console/Kernel.php file. This method should return the default timezone that should be assigned to all scheduled tasks:

/**
 * スケジュール済み全イベントに対するデフォルトのタイムゾーンを取得
 *
 * @return \DateTimeZone|string|null
 */
protected function scheduleTimezone()
{
    return 'America/Chicago';
}

中間テーブル／ピボットモデルイベントIntermediate Table / Pivot Model Events

以前のバージョンのLaravelでは、多対多リレーションのカスタム中間テーブル／ピボット（"pivot"）モデルのアタッチ（attach）、デタッチ（detach）、同期（sync）時に、Eloquentモデルイベントはディスパッチされませんでした。Laravel5.8のカスタム中間テーブルモデルを使用する場合、適切なモデルイベントがディスパッチされるようになりました。In previous versions of Laravel, Eloquent model events[/docs/{{version}}/eloquent#events] were not dispatched when attaching, detaching, or syncing custom intermediate table / "pivot" models of a many-to-many relationship. When using custom intermediate table models[/docs/{{version}}/eloquent-relationships#defining-custom-intermediate-table-models] in Laravel 5.8, the applicable model events will now be dispatched.

Artisan callの向上Artisan Call Improvements

LaravelではArtisanをArtisan::callメソッドにより起動できます。以前のLaravelリリースでは、メソッドの第２引数として、配列でコマンドオプションを渡していました。Laravel allows you to invoke Artisan via the Artisan::call method. In previous releases of Laravel, the command's options are passed via an array as the second argument to the method:

use Illuminate\Support\Facades\Artisan;

Artisan::call('migrate:install', ['database' => 'foo']);

Laravel5.8では、メソッドの第１引数へ、オプションを含めたコマンド全体を渡せるようになりました。However, Laravel 5.8 allows you to pass the entire command, including options, as the first string argument to the method:

Artisan::call('migrate:install --database=foo');

mock/spyテストヘルパメソッドMock / Spy Testing Helper Methods

モックオブジェクトをより便利にするため、ベースのLaravelテストケースクラスへ新しくmockとspyメソッドを追加しました。これらのメソッドは自動的にモッククラスをコンテナへ結合します。例をご覧ください。In order to make mocking objects more convenient, new mock and spy methods have been added to the base Laravel test case class. These methods automatically bind the mocked class into the container. For example:

// Laravel5.7
$this->instance(Service::class, Mockery::mock(Service::class, function ($mock) {
    $mock->shouldReceive('process')->once();
}));

// Laravel5.8
$this->mock(Service::class, function ($mock) {
    $mock->shouldReceive('process')->once();
});

Eloquentリソースキーの保持Eloquent Resource Key Preservation

ルートよりEloquentリソースコレクションが返されるとき、Laravelはコレクションのキーをシンプルな数値順へリセットします。When returning an Eloquent resource collection[/docs/{{version}}/eloquent-resources] from a route, Laravel resets the collection's keys so that they are in simple numerical order:

use App\User;
use App\Http\Resources\User as UserResource;

Route::get('/user', function () {
    return UserResource::collection(User::all());
});

Laravel5.8を使用する場合、リソースクラスにpreserveKeysプロパティを追加し、コレクションのキーの保持をLaravelへ指示してください。以前のLaravelリリースと一貫性を保つために、デフォルトでキーはリセットされます。When using Laravel 5.8, you may now add a preserveKeys property to your resource class indicating if collection keys should be preserved. By default, and to maintain consistency with previous Laravel releases, the keys will be reset by default:

<?php

namespace App\Http\Resources;

use Illuminate\Http\Resources\Json\JsonResource;

class User extends JsonResource
{
    /**
     * リソースコレクションのキーの保持を指定
     *
     * @var bool
     */
    public $preserveKeys = true;
}

preserveKeysプロパティがtrueのとき、コレクションキーは保持されます。When the preserveKeys property is set to true, collection keys will be preserved:

use App\User;
use App\Http\Resources\User as UserResource;

Route::get('/user', function () {
    return UserResource::collection(User::all()->keyBy->id);
});

Higher Order orWhere EloquentメソッドHigher Order orWhere Eloquent Method

以前のリリースのLaravelでは、複数のEloquentモデルスコープを結合するために、orクエリ操作でクロージャコールバックを使用する必要がありました。In previous releases of Laravel, combining multiple Eloquent model scopes via an or query operator required the use of Closure callbacks:

// scopePopularとscopeActiveメソッドは、Userモデルで定義済み
$users = App\User::popular()->orWhere(function (Builder $query) {
    $query->active();
})->get();

Laravel5.8では、"higher order" orWhereメソッドが導入され、クロージャを使用することなく、スコープをすらすらとチェーンできます。Laravel 5.8 introduces a "higher order" orWhere method that allows you to fluently chain these scopes together without the use of Closures:

$users = App\User::popular()->orWhere->active()->get();

Artisan Serveの向上Artisan Serve Improvements

以前のLaravelリリースでArtisan serveコマンドは、ポート8000固定でアプリケーションのサーバ動作していました。他のserveコマンドプロセスが既にこのポートをリッスンしている場合、次に起動を試みたserveは失敗していました。Laravel5.8から複数のアプリケーションを一度にサーバ動作できるように、serveは最大で8009ポートまで利用可能なポートをスキャンするようになりました。In previous releases of Laravel, Artisan's serve command would serve your application on port 8000. If another serve command process was already listening on this port, an attempt to serve a second application via serve would fail. Beginning in Laravel 5.8, serve will now scan for available ports up to port 8009, allowing you to serve multiple applications at once.

BladeファイルのマッピングBlade File Mapping

Bladeテンプレートをコンパイルするとき、Laravelはコンパイル済みファイルの先頭へ、オリジナルのBladeテンプレートへのパスを含めるようになりました。When compiling Blade templates, Laravel now adds a comment to the top of the compiled file which contains the path to the original Blade template.

DynamoDBキャッシュ／セッションドライバDynamoDB Cache / Session Drivers

Laravel5.8からDynamoDBキャッシュとセッションドライバが導入されました。DynamoDBはAmazon Web Servicesが提供する、サーバレスNoSQLデータベースです。dynamodbキャッシュドライバーのデフォルト設定は、Laravel5.8のキャッシュ設定ファイルで確認できます。Laravel 5.8 introduces DynamoDB[https://aws.amazon.com/dynamodb/] cache and session drivers. DynamoDB is a serverless NoSQL database provided by Amazon Web Services. The default configuration for the dynamodb cache driver can be found in the Laravel 5.8 cache configuration file[https://github.com/laravel/laravel/blob/master/config/cache.php].

Carbon2.0サポートCarbon 2.0 Support

Laravel5.8は、Carbon日付操作ライブラリの~2.0リリースをサポートしました。Laravel 5.8 provides support for the ~2.0 release of the Carbon date manipulation library.

Pheanstalk4.0サポートPheanstalk 4.0 Support

Laravel5.8はPheanstalkキューライブラリの~4.0リリースをサポートしました。Pheanstalkライブラリをアプリケーションで利用している場合は、Composerで~4.0リリースへアップグレードしてください。Laravel 5.8 provides support for the ~4.0 release of the Pheanstalk queue library. If you are using Pheanstalk library in your application, please upgrade your library to the ~4.0 release via Composer.