At Spatie we've released a plethora of Laravel packages. Now that Laravel 5.5 has been released most of our packages will get a new (major) version. In this blogpost I'd like to explain how we handle new releases of the framework and what it means for our packages.

Preparing for release

Laravel has a bi-yearly release cycle. It doesn't follow semver. Breaking changes are often introduced in point releases. That's why our Laravel packages mostly have very conservative composer constraints on them so that they are not installable in future versions of the framework. Every half year we go through them all, make sure that they are compatible with the latest and greatest version of the framework and tag new releases. We try to do this as quickly as possible after a new stable Laravel release has been tagged.

In previous releases of Laravel we've waited working a new versions of our stuff until the newest version of the framework was publicly available. The rationale behind this was that even in the last days before Laravel's release breaking code may be introduced, so it's best to create compatible packages after the release. Looking at the past learns us that a few weeks before a new version of Laravel gets released the development version is already pretty stable. That's why this time around we created laravel-55 branches to make our code compatible ahead of Laravel's release.

Auto discovery

Laravel 5.5 has an awesome new feature called package auto-discovery. There's no need anymore to manually register service provides and facades. Laravel will now automatically do that for you. It does this by looking at a special extra key in the composer.json of a package. All our L5.5 compatible packages will support this feature.

Let's take a look at a small package of ours that utilises this: laravel-tail. That one provides an artisan command to tail the logs. The only thing you need to do in a Laravel 5.5 application is composer require spatie/laravel-tail. The service provider gets registered automatically which in it's turn registers an artisan command in the kernel. You can just use the php artisan tail command. It's that simple.

Leaving older framework versions behind

Laravel 5.5 is a new LTS release. Personally I'm not a big fan of the concept of LTS, but in this case, for some packages, I'm grabbing the opportunity to break compatibility with previous versions of Laravel so I can make use of new features introduced in Laravel 5.5. Examples are laravel-feed, laravel-medialibrary, laravel-collection-macros, ... which all are getting new major releases. Even though we're not going to support the older versions actively anymore, the old major versions should all be pretty stable. We won't release any new features for older versions of our packages, but we will still accept PRs for bugfixes for quite some time.

In the past we've named our config files laravel-<package-name>. We're going to simplify that by dropping the laravel- prefix. So config/laravel-backup.php just becomes config/backup.php.

Leaving packages behind

Laravel 5.5 contains many new features. Some of the features will replace things that we already had in place via our packages.

Take dd and dump macros for instance. We've been using those already for a long time in our projects. We've included them in v2 of laravel-collection-macros. Laravel now has dd and dump functions on the collection by default, no need to macro them anymore.

Laravel has this really sweet functionality to build up json reponses for your API. It does more or less the same than Fractal but in a more integrated way. For most projects I'm probably going to use Laravel's baked in solution, but I still plan on maintaining our popular laravel-fractal package for people who want to use it in their Laravel app.

We have a package called laravel-failed-job-monitor that can send you a notification whenever a queued job fails. Laravel Horizon is a new awesome looking dashboard for managing queued job. It can also send notifications when something goes wrong. We are probably going to use Horizon for all our future projects. That's why we are leaving our own laravel-failed-job-monitor behind.

I'm really happy that the entire functionality of two of our packages is now included in the framework. For these two we are not going to create a Laravel 5.5 version, but we'll still do maintainance on the current version:

• laravel-migrate-fresh: This package provides an artisan command that can rebuild your entire database. It does this by dropping all tables first and then running all up migrations. You don't need to write any `down` migrations. Our package triggered the work that resulted the `migrate:fresh` command being included in Laravel itself.

• laravel-tinker-tools: When working with `tinker` it's kinda bothersome that you need to type the fully qualified class name. Wouldn't it be nice of you could just use the short class name? That's exactly what this package does. So instead of typing `App\Models\BlogPost::first()` you can do `BlogPost::first()`. The code of this package was ported to the `laravel/tinker` package. Laravel 5.5 ships with this feature out of the box.

In conclusion

Laravel 5.5 is probably the best release yet. But, in all honesty, I think that of every Laravel release. My recommendation is to get your apps upgraded to this version as soon as possible. The reward is that you can make use of all L5.5's new features and the latest major versions of our packages. Keep an eye out on my Twitter account to learn which of our packages are tagged as L5.5 compatible. You'll find a full list of our Laravel packages on our company website.