Bringing Flare back to Laravel 10 and PHP 8.1

Here at Spatie, the creators of Flare and over 400 PHP and Laravel packages, we always try to push to the latest versions of PHP and Laravel. It's pretty much always a good idea.

For Flare we make an exception. We'd love to give all our customers the newest features like performance monitoring and logs, no matter which version they're on. So we decided to again start supporting Laravel 10 and PHP 8.1.

Because if you were still on Laravel 10, you were stuck on an older Flare. And especially with performance monitoring and logging, that means missing out on the best stuff we've built in recent months. That's something we don't want.

A chain of dependencies

This wasn't one version bump. Flare on Laravel is a small stack: laravel-flare sits on top of flare-client-php (the framework-agnostic core), flare-daemon and laravel-error-share. You can widen the laravel-flare version compatibility all you want, but if the packages underneath still demand Laravel 11, Composer just refuses.

So it had to move from the bottom up. First the core and flare-daemon reach down to PHP 8.1, then laravel-error-share, then finally laravel-flare itself.

Why stop at PHP 8.1?

PHP 8.1 is where we drew the line, and that's on purpose.

Enums landed in PHP 8.1, and we use them everywhere across the codebase. Going lower would mean losing them and replacing the enums with something clunkier. We'd do that with pain in the heart, and it would force a new major release on everyone, something we recently did with version three of the Flare packages and something we hope to avoid in the future.

Laravel 9 and lower didn't make the cut either, and here the reason is very practical. Testbench for Laravel 9 has no workbench, the little app we boot to run our integration tests against. And that integration test is the whole reason this port was even doable, but we come back to that later on.

Letting AI do the tedious part

There weren't a lot of changes we needed. For the framework agnostic client, it was merely changing some dependencies and we were done.

Downgrading the Laravel dependency was a bit more difficult:

• The store names were missing from cache events
• Specific container hooks we've been using, like "registered", don't exist
• The queueable trait wasn't invented yet
• And a few smaller things

Most of the fixes were small, but there were a lot of them, spread across source, tests, workbench and CI. The perfect work for an AI agent. Not because it's clever, but because it's a grind with a tight feedback loop.

And that loop is the fun part.

Our massive integration test

Flare has one integration test that does an absurd amount. It boots a real Laravel app, starts an HTTP server and a queue worker, fires requests, runs jobs, and asserts that the exact spans, logs and errors Flare should record actually show up. Hundreds of assertions across the whole framework in one run.

Which makes something like this almost easy. Point the same test suite at Laravel 10 and it immediately tells you every spot where behaviour drifts.

So the agent could just loop: run the suite, find out what failed, fix, repeat, across the whole version matrix until everything turned green.

So welcome to the future of Flare, even when you're still on an older PHP or Laravel version!