Laravel 10.37, weekly updates, and 🔥 deals

Laravel 10.37

Couple fixes and new features this week brings us to Laravel 10.37. Astute readers will wonder what happened to 10.36 - this release got double tagged.

Anyway, here are the highlights:

  • Add engine() to Blueprint in #49250
  • Add noActionOnUpdate()to ForeignKeyDefinition in #49297
  • Enable DynamoDB as a backend for job batches in #49169
  • Add Conditionable to batched and chained jobs in #49310
  • Allow arrayable and stringables passed to in and notIn rules in #49055
  • Allow asserting multiple errors per field in #49309

You may review the full branch diff on GitHub for a complete list of changes.

This version bump and update is automated for subscribers to a Shifty Plan. If you don't have one of those, be sure to bump your constraint and run composer update to get the latest features.

Weekly Journal

Last week was pretty busy. I continued work on the side-project, mostly writing content for the landing and documentation page. I also took some time to backfill tests for my Livewire components.

In the process, I found a few areas that could use stronger assertions. So I sent a PR to both Laravel and Livewire. It didn't make it in this release, but hopefully next time.

Over the weekend I merged a massive PR into Blueprint. It improves support for UUID and ULID primary keys.

I also finished up the last Human Shift. Although another came in today. So I'll work on that later this week.

Hopefully next week I'll launch the side-project and get back to working on the Laravel 11.x Shift.

🔥 Tip

In backfilling the tests for the side-project I finally took the time to explore recycle. Similar to Shift, the side-project has interdependent relationships. For example, a Project relates to a Repository which relates to a Connection. All of which belong to a User.

My model factory definitions contain something like:

'user_id' => User::factory(),
'connection_id' => Connection::factory(),

However, when I create a Repository factory, its user is different than the user for the related Connection factory it creates.

So, how do you ensure they are all related together correctly? Well, obviously you create each factory one-by-one and set the user yourself (tedious). You might use some of the fluent methods to streamline it (maybe). You may try to handle things programmatically using attribute callbacks (complex).

Or you may simply use recycle:

Repository::factory()
    ->recycle(User::factory()->create())
    ->create();

In doing so, the factory passed to recycle will be used by any factories creating a factory of that type. In this case, the Repository will use it and so will its Connection. So all my relationships are correctly related to the same user. All with one little method call.