Laravel 5.5LTS の新機能

2017年8月30日にリリースされたLaravel 5.5LTSの新機能まとめ。

5.5は5.1以降2年振りのLTS(Long-Term Support)だ。バージョン追従が難しい商用プロダクトなどは、LTSをベースに開発するのが良い。

以下は、Laravel NewsのLaravel 5.5 LTS is Now Releasedの翻訳。文章がこなれていないところや翻訳が怪しいところもあるが、何かあればご連絡ください。

Laravel 5.5は次のLTSリリース

Laravel 5.5は次の長期サポート(LTS=Long-Term Support)バージョン（前回は5.1）。LTSは、２年間のバグ修正、３年間のセキュリティ修正を行う。

一般的なマイナーリリースでは、半年間のバグ修正、１年間のセキュリティ修正となっている。

Whoopsパッケージ

Laravel v4で提供されていたデバッグ時にエレガントなスタックトレースを行ってくれる flip/whoops が、Laravel 5.5で復活！

Collectionのダンプ

もう一つの素晴らしいデバッグであるcollectionのダンプメソッドがされる：

<?php

Song::all()
    ->filter
    ->platinum
    ->dump()
    ->filter(function ($song) {
        return $song->released_on >= \Carbon\Carbon::parse('-10 years');
    })
    ->dd();

詳しくは、collectionダンプの記事を参照のこと。

例外のレンダリング

パブリックな"response"メソッドを定義すれば、例外はレスポンスをレンダリングできる。以前のバージョンのLaravelでは通常、App\Exceptions\Handler::render() のメソッドにチェックを追加して例外種別に基づいてレスポンスを返すことが必要だった。

5.5では、ただ例外を投げるだけで、ハンドラで追加のロジックを書かずに応答することができる：

<?php

// throw new TerribleSongException($song) in a controller...

namespace App\Exceptions;

use App\Song;

class TerribleSongException extends \Exception
{
    /**
     * @var \App\Song
     */
    protected $song;

    public function __construct(Song $song)
    {
        $this->song = $song;
    }

    /**
     * @param \Illuminate\Http\Request $request
     */
    public function render($request)
    {
        return response("The song '{$this->song->title}' by '{$this->song->artist}' is terrible.");    
    }
}

例外クラスでRespansableインタフェースを実装することでも、Laravelは自動的に応答する。

Responsableインタフェース

Responsableインタフェースは、Laravel newsで既に取り上げたが、laravelへのもう一つの応答の追加。このインタフェースを実装したクラスは、コントローラーのメソッドから返すことができる。 Illuminate\Routing\Routerから応答を準備するときに、ルータはResponsableインスタンスを確認する。

応答の詳細をNewSongResponseオブジェクトに委ねる例：

public function store(Request $request)
{
    $data = request()->validate([
        'title' => 'required',
        'artist' => 'required',
        'description' => 'required',
        'duration' => 'required|numeric',
        'released_on' => 'required|date_format:Y-m-d',
        'gold' => 'boolean',
        'platinum' => 'boolean',
    ]);

    $song = new Song($data);
    $song->save();

    return new NewSongResponse($song);
}

新しいSongオブジェクト生成の際のResponsableインタフェースの実装はこうなる：

<?php

namespace App\Http\Responses;

use App\Song;
use Illuminate\Contracts\Support\Responsable;

class NewSongResponse implements Responsable
{
    /**
     * @var \App\Song
     */
    protected $song;

    /**
     * @param \App\Song $song
     */
    public function __construct(Song $song)
    {
       $this->song = $song; 
    }

    public function toResponse($request)
    {
        if ($request->wantsJson()) {
            return response()
                ->json($this->song)
                ->header('Location', route('songs.show', $this->song))
                ->setStatusCode(201);
        }

        return redirect()
            ->route('songs.show', $this->song);
    }
}

この簡単な例では、AJAX経由のリクエストの場合は自動的にJSONで応答し、ディフォルトではshongs.showルートにリダイレクトする。

リクエストバリデーションメソッド

従来のバージョンのLaravelでは、コントローラ内で$this->validate()にリクエストのインスタンスを渡していた：

$this->validate(request(), [...]);

これからはリクエストオブジェクトに対してvalidateを呼ぶだけだ：

$data = request()->validate([
    'title' => 'required',
    'artist' => 'required',
    'description' => 'required',
    'duration' => 'required|numeric',
    'released_on' => 'required|date_format:Y-m-d',
    'gold' => 'boolean',
    'platinum' => 'boolean',
]);

このスタイルでのバリデーションの呼び出し方法のさらに良いところは、リターン値がRequest::only()と同様に振る舞うところ、つまり、バリデーションの呼び出しで指定されたキーのみが返されるところだ。Request::all()を使わずにバリデーションを通ったキーのみを返すことは良い慣習となる。

カスタムバリデーションルールのオブジェクトとクロージャ

Laravel 5.5で私が好きな機能は、新しいカスタムバリデーションルールオブジェクトとクロージャが簡単に作れるところだ。カスタムルールオブジェクトを作るのは、Validator::extend（まだ使えますが）を使ってカスタムルールを作るより優れた方法になる。なぜなら、ルールロジックが一目でわかるからだ。バリデーションルールオブジェクトは以下のようになる：

<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;

class CowbellValidationRule implements Rule
{
    public function passes($attribute, $value)
    {
        return $value > 10;
    }

    public function message()
    {
        return ':attribute needs more cowbell!';
    }
}

この検証ルールを使う例：

<?php

request()->validate([
    'cowbells' => [new CowbellValidationRule],
    'more_cowbells' => [function ($attribute, $value, $fail) {
        if ($value <= 10) {
            $fail(':attribute needs more cowbell!');
        }
    }]
]);

クロージャ形式には属性、値、そしてバリデーションルールに失敗した時に呼び出されるfail関数をパラメータとしてとる。クロージャは、専用のルールオブジェクトを作る前に実験的にカスタムバリデーションを試したり、一度きりのカスタムバリデーションを行う場合に便利だ。

カスタムバリデーションルールオブジェクトを作るためのmake:ruleコマンドが用意された。

$ php artisan make:rule MyCustomRule

Laravel Newsにカスタムバリデーションルールに特化した記事があるので、こちらも要チェック。

AuthとGuest Blade命令

5.5でのBlade::if()命令については既に書いた。また、5.5では新しい条件命令、@auth と @guestがある。

通常、Bladeで認証されたユーザかどうかをチェックするのは次のようにする：

@if(auth()->check())
    {{ -- authenticated --}}
@endif

@if(auth()->guest())

今度からは次の命令を使うことで同じことが可能となる：

@auth
    Welcome {{ user()->name }}!
@endauth

@guest
    Welcome Guest!
@endguest

フロントエンドプリセット

新しいプロジェクトを始める際、Laravel 5.5はVue.js scaffoldingを標準で提供している。"preset" Artisanコマンドを使うと、フロントエンドscaffoldingに関して、いくつかの規定値から選択したり、何も使わないと行ったことが指定できる。

helpで分かるように、"none", "bootstrap", "vue", "react"の中から選ぶことができる：

php artisan help preset
Usage:
  preset <type>

Arguments:
  type    The preset type (none, bootstrap, vue, react)

# Use react
$ php artisan preset react

# Clear scaffolding
$ php artisan preset none

分離されたファクトリーファイル

ファクトリーファイルは以前はひとつのModelFactory.phpファイル内で定義されていた。今度は、model毎に別々のファイルを作ることが可能となった。新しいモデルを作る際に、ファクトリーファイルを作ることができる：

$ php artisan make:model -fm Post

# Or you can create a controller, migration, and factory
$ php artisan make:model --all

また、ファクトリーファイルを"make:factory"を使って直接作ることも可能：

$ php artisan make:factory --model=Example ExampleFactory

migrate:freshマイグレーションコマンド

新しい“migrate:fresh”マイグレーションコマンド 5.5は、開発中にクリーンなデータベースを作成するための素晴らしい追加機能だ。migrate:refresh小窓はデータベースのテーブルを全て削除(drop table)してからマイグレーションを実行する。

従来のmigrate:refreshコマンドに慣れているかもしれないが、それはマイグレーションをロールバックしてから再度マイグレーションを実行していた。通常、開発中は単にテーブルを削除して、新規にデータベースを作成して、マイグレーションを実行したいだろう。

RefreshDatabaseトレイト

テストの最前線において、RefreshDatabaseトレイトはテスト中にデータベースを移行する新しい方法だ。この新しいトレイとは、インメモリデータベースを使っているか従来型データベースを使っているかによって最適な移行方法を採用する。DatabaseTransactionsトレイトやDatabaseMigrationsトレイトは5.5でも利用可能なので、新しいRefreshDatabaseトレイトを使わなくともアップグレードは可能だ。

withoutExceptionHandling()メソッド

基本テストケースは、テストのために例外処理を無効化したwithoutExceptionHandling()メソッドを継承する。例外処理を無効化すれば、テストの中で例外を捕捉し、例外ハンドラの応答を使う代わりに例外をアサートすることができる。これは期待しないことをテストする時に、実際の例外を見たい場合、便利なデバッグツールとなる。

自動パッケージ検出

最後は自動パッケージ検出について見てみます。Laravelパッケージは通常インストールするのは難しくはないし、パッケージ検出機能によりproviderやaliasをセットアップする必要もなくなる。特定のパッケージに対して自動検出を無効とすることも可能。

さらに学ぶには、Taylor Otwellの記事や我々の記事を参照のこと。

Laravel 5.5についてさらに学ぶには

さらに深くみていくには、Laravel 5.5コンテンツを必ずチェック。Laracastはこれら全ての機能について"網羅"している。また、公式ドキュメント、リリースノート、アップグレードガイドもチェックして。

(original English article was written by Paul Redmond)