What Are the New Features in Laravel 5.5?

Laravel 5.5 will require PHP 7.0+. For the features this modern PHP version brings, please see our recap.

Laravel 5.5 will also be the next LTS (Long Term Support) release. This means bugfixes for two years and three years of security updates. That was also the case with Laravel 5.1, but its two-year window of bug fixes is coming to an end this year. Without further ado, let's see what this new version has to offer.

Creating a New Laravel 5.5 Project

Since the release has not yet officially happened, we can install the dev release version by running the command:

laravel new laravel55 --dev
cd laravel55
php artisan key:generate

If you prefer not to use the Laravel installer, you can also take the Composer approach:

composer create-project --prefer-dist --stability=dev laravel/laravel:dev-master
cd laravel
php artisan key:generate

Once we visit the homepage of the newly set up app, we should be greeted with a welcome page similar to what we used to have in previous Laravel versions.

Rendering Mailables to the Browser

I feel this is something that will come in very handy. In the previous Laravel versions, we had to send actual emails or use an email client like Mailtrap to test email layouts, and this wasn't a fun task. This won't be the case any more, as with Laravel 5.5 it's possible to render the email layout to the browser directly.

A quick walkthrough on how to achieve this: let's create a new mailable as well as the email template for our current project:

php artisan make:mail Welcome --markdown=emails.welcome

I prefer the markdown approach since we will get a template with some content already. Let's open our web.php file and create a test route to checkout the email layout:

Route::get('/email', function () {
    return new App\Mail\Welcome();
});

routes/web.php

By visiting the route /email we should be able to preview the email template:

What's actually going on under the hood is that with Laravel 5.5, the Mailable class implements the Renderable contract which has a render() method. This is the implementation of the render() method inside lluminate/Mail/Mailable.php:

public function render()
{
    Container::getInstance()->call([$this, 'build']);

return Container::getInstance()->make('mailer')->render(
        $this->buildView(), $this->buildViewData()
    );
}

lluminate/Mail/Mailable.php

This is the method that makes it possible to get a view. Had we tried returning an instance of a class that does not implement the Renderable contract within our routes, we'd get an UnexpectedValueException thrown.

Custom Email Themes

When using Markdown for emails, Laravel will provide a default theme. However, some people may prefer having some custom styling in their email templates for branding purposes.

To use a custom theme for a particular mailable, we first create a custom .css file containing the styles we want:

touch resources/views/vendor/mail/html/themes/custom.css

We then then specify this filename as a property in the Mailable class:

class Welcome extends Mailable
{
    protected $theme = 'custom';
    [...]
}

app/Mail/Welcome.php

This way, the email layout will be based on the styles we defined in the custom.css file. The good thing with this approach is that we can have different themes for different mailables.

Exception Helper Functions

Laravel 5.5 comes with two exception helper functions which will help us write more expressive code. The two helpers are the throw_if and throw_unless methods. Both take three arguments with the third argument being optional.

Let's look at the different implementations of these exceptions:

$number = 2;
throw_if($number !== 3, new NotThreeException('Number is not three'));
// or
throw_if($number !== 3, NotThreeException::class, 'Number is not three');

With the throw_if helper, an exception will be thrown if the first argument evaluates to true.

Implementing the throw_unless helper is no different from what we did above, the only difference being that an exception will only be thrown if the first argument evaluates to false:

$number = 2;
throw_unless($number === 3, new NotThreeException('Number is not three'));
// or
throw_unless($number === 3, NotThreeException::class, 'Number is not three');

Not the best example, but serves our demonstration purposes.

Introducing the migrate:fresh Command

You've probably found yourself in a situation that required you to rebuild the database. With previous Laravel versions, we achieved this by running the php artisan migrate:refresh command. The migrate:refresh command rolls back all migrations based on what is specified in the down method for each migration file then runs the migrations again:

But you've probably run into issues with this command a couple of times, especially when working with foreign key constraints or say you have a down() method in one of your migrations that has not been well defined. When that happens, we resort to dropping the table raising issues manually most of the time - (could be from the CLI or some GUI). That's where migrate:fresh comes to our rescue. This command drops all the tables, then runs the existing migrations again:

JSON Error Stack Traces

Not a really big change but then in previous Laravel versions, we'd see HTML markup from an API client such as Postman every time we got an error while building out APIs. In Laravel 5.5, we get a JSON stack trace rather than HTML markup if an error occurs which looks neater and easier to follow:

Automatic Package Discovery

These are the steps we follow in order to use a third party package in our Laravel projects.

• Install the package
• Register the package's service provider
• Register facades if any

As you can see, it could be simpler. Now it is.

With automatic package discovery, we'll just require a package and start using it on the fly. Note, however, this only happens if the package provider has configured the package for autodiscovery.

Looking at the Laravel Debugbar package which has already been updated for package autodiscovery, we see that there is an extra section inside the composer.json file:

"extra": {
    "laravel": {
        "providers": [
            "Foo\\Bar\\ServiceProvider"
        ],
        "aliases": {
            "Bar": "Foo\\Bar\\Facade"
        }
    }
}

Package providers will have to update the composer.json file with an extra section, then specify the providers and any aliases for the package.

Another good thing with automatic package discovery is that things won't break after removing a dependency. Normally, even after uninstalling a package we still have the package's service providers and facades hanging around in the config/app.php file and this may raise issues in some cases.

With package autodiscovery, when a package is removed via Composer, then everything related to the package is also removed.

Continue reading %What Are the New Features in Laravel 5.5?%