What’s New in Laravel 6: Ignition and Flare

September 30, 2019
Written by
Twilion

Copy of Photo blog Header 1(1).png

Laravel 6.0 is released, and as a new major version, there are plenty of fun new features for us to play with. The release notes give us all the highlights, but as part of a recent stream, I decided to take a look at one of the more exciting additions, the new error handler, Ignition.

Ignition

Ignition replaces Whoops as the default error handler in Laravel 6, but it works on older Laravel applications going back to version 5.5. The impressive thing about Ignition is because it's designed from the ground up to handle Laravel's specific errors, it can make suggestions on how to resolve errors, and even automatically fix common problems for us.

If we deliberately add a typo in our blade template name, then Ignition realises this and suggests the fix for us in the green panel.

Screenshot of Ignition detecting a typo of "homex" and suggesting that we meant to type "home"

Even smarter is the fact that Ignition can automatically fix some common problems that it can detect. Removing the application key from our .env file is detected, and along with telling us the solution, Ignition offers to fix it for us too.

Screenshot of Ignition detecting a missing app key, and suggesting to generate a new app key itself

As well as the problem definition and suggested fixes, we get everything expected from an error handler - a full stack trace, information about the request and the server, but we also get a lot of Laravel specific information. Ignition tells us which route was hit and consequently which controller and action. It also displays which view template was rendered if any, and which middlewares have run.

We also get some beneficial debug information. Any logging or debug dumps done handling the request are visible and so are any database queries that have run. All in all you get a massive amount of information to help you diagnose the problem quickly and easily.

Animated GIF showing each of the tabs on the information pane of Ignition

 

A nice touch that I find very useful is the ability to click on any line in the stack trace, and if you're using PhpStorm, it opens that file and line right in the editor. This is going to save so much time and energy.

On its own, Ignition is a great new error handler for Laravel, and it can only improve as the community contributes more common problems and solutions. It's also extensible, with several first-party and community extensions already available.

Flare

It doesn't stop there. Facade, the company behind this new open-source error handler have also created a paid SaaS product called Flare, which complements its functionality. You can tell Ignition to marshal all your errors to the Flare web application so that all the errors are visible in one place.

Setting it up is straightforward enough, you have to add some extra information to Laravel's config, and away we go. Once Flare is set up, we can use an Artisan command to check that it's working and send a test event to the Flare application.

php artisan flare:test

Screenshot of Flare with the test exception displayed

We can see that our test exception reaches Flare correctly, but now, if we refresh our original error page with the misnamed view template, that reaches Flare too, and we get all the original error information we got from Ignition.

While this might not sound so remarkable, it's designed with production in mind so that you can see any errors that are happening in your live application but with all of the data you'd get from Ignition in your development environment. We can see how this works locally by putting Laravel into production mode. To do that we set the APP_ENV key to production and turn the APP_DEBUG to false in the .env config file.

Now, when we hit the same page that was erroring, we see a nicely formatted 500 page which doesn't reveal anything about your code or what caused the error to our users.

Screenshot of a minimalist error page reading "500 | Server Error"

The error still gets sent to Flare, which means that when your users are reporting a problem, you can find out exactly what went wrong quickly and easily. Because Ignition records the logged-in user's information validating it's the correct error is pretty simple too.

It's always an excellent idea to keep your log files as empty as possible in production so that you can find errors quickly and easily. Making sure you fix any warning and deprecation messages in your logs is fundamental to running a healthy production system where errors can be detected quickly and dealt with efficiently. Ignition and Flare take this to the next level and make the handling of errors in both development and production a breeze. Kudos to the team at Facade and all the contributors for a remarkable effort.

If you’re running Laravel 6.0 and using Ignition or if you’ve dropped it into your older Laravel project, I’d love to know what you think. Tweet at me or leave a comment and give me your opinions on Laravel’s new error handler.

I can’t wait to see what you build.