バージョニング規約Versioning Scheme
Laravelのバージョニングは、「パラダイム.メジャー・マイナー」の規約を維持しています。メジャーフレームワークリリースは、1月と6月の半年ごとにリリースします。一方、マイナーリリースは毎週のように、頻繁にリリースされます。マイナーリリースは、ブレーキングチェンジを絶対に含めません。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リリースでは、バグフィックスは2年間、セキュリティフィックスは3年間提供します。これらのリリースは長期間に渡るサポートとメンテナンスを提供します。 一般的なリリースでは、バグフィックスは6ヶ月、セキュリティフィックスは1年です。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 | 2015年2月4日February 4th, 2015 | 2015年8月4日August 4th, 2015 | 2016年2月4日February 4th, 2016 |
5.1 (LTS)5.1 (LTS) | 2015年5月9日June 9th, 2015 | 2017年6月9日June 9th, 2017 | 2018年6月9日June 9th, 2018 |
5.25.2 | 2015年12月21日December 21st, 2015 | 2016年6月21日June 21st, 2016 | 2016年12月21日December 21st, 2016 |
5.35.3 | 2016年8月23日August 23rd, 2016 | 2017年2月23日February 23rd, 2017 | 2017年8月23日August 23rd, 2017 |
5.45.4 | 2017年1月24日January 24th, 2017 | 2017年7月24日July 24th, 2017 | 2018年1月24日January 24th, 2018 |
5.5 (LTS)5.5 (LTS) | 2017年8月30日August 30th, 2017 | 2019年8月30日August 30th, 2019 | 2020年8月30日August 30th, 2020 |
5.65.6 | 2018年2月7日February 7th, 2018 | 2018年8月7日August 7th, 2018 | 2019年2月7日February 7th, 2019 |
5.75.7 | 2018年9月4日September 4th, 2018 | 2019年3月4日March 4th, 2019 | 2019年9月4日September 4th, 2019 |
5.85.8 | 2019年2月26日February 26th, 2019 | 2019年8月26日August 26th, 2019 | 2020年2月26日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:
AuthServiceProvider
中で明確にマップされたポリシーは、自動検出される可能性のあるポリシーよりも優先的に扱われます。{note} Any policies that are explicitly mapped in yourAuthServiceProvider
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リリースでは、メソッドの第2引数として、配列でコマンドオプションを渡していました。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では、メソッドの第1引数へ、オプションを含めたコマンド全体を渡せるようになりました。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.