Laravel 12.13, weekly updates, and weekly tip

Laravel 12.13

Lots of patch releases last week and lots of new features this week brings us to Laravel 12.13.0.

• Add support for callback evaluation in containsOneItem in #55622
• Allow naming queued closures in #55634
• Add assertRedirectBack assertion in #55635
• Queue event listeners with enum values in #55656
• Implement releaseAfter for RateLimited middleware in #55671
• Only pass model id to Eloquent whereAttachedTo in #55666
• Allow adding multiple jobs to chain in #55668

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

Still adjusting to Daddy Daycare. Any computer time I have is in short bursts. So it's mainly answering support emails, being active on Twitter, and pairing with JT. I also squeezed in my Wednesday livestream.

The main thing I'm trying to finish is a migration to Stripe's Billing Portal. This wasn't available when I built Shift 10 years ago. Nothing was available really. Spark wasn't released. Cashier was barely v1. I just threw Stripe's checkout.js on the page and did one-off charges. It's been a bit of a frog in a pot situation ever since. I've effectively built my own custom billing portal.

Needless to say, that's been a large endeavor. Furthermore, there's a lot of edge cases. Now that I'm doing more with subscriptions, increasing Purchasing Power Parity, using coupons, it makes sense to stop and ask, "should I switch?"

The answer is yes. It actually hasn't been that bad. I'm about 5 hours in and it's pretty much done. Honestly, linking to Stripe Checkout was easy. Really just a single Cashier call. The tedious stuff was backfilling my products into Stripe with various local pricing. Then reflecting that pricing back on laravelshift.com.

Anyway, I hope to complete the first phase (single Shift checkout) this weekend. Then continue on phase 2 (subscriptions) next week.

Weekly Tip

Dyrynda made a video on better testing by improving your failure messages. It's funny, JT and I had a similar discussion in a recent pairing session. While I'd still encourage you to watch the video, the takeaway is to use assertions within "truth test" callbacks.

For example, instead of:

Queue::assertQueued(
    PublishPodcast::class,
    fn ($job) => $job->podcast->is($podcast)
);

You would use assertions.

Queue::assertQueued(function (PublishPodcast $job) use ($podcast) {
    $this->assertTrue($job->podcast->is($podcast));
 
    return true;
});

Now, I definitely like this from an improved error message perspective. Especially when verifying multiple values or for more complex logic.

A few things I don't like. First, it's much more verbose. No short closure. Lengthy assertions. The explicit return true. Second, while the line numbers will line up better, there's no guarantee using an assertion gives you a better message. In this case, you still get a generic "failed asserting false is true" message.

I actually used to write code this way. I think following Freek's advice. But there was an instance where using assertions within these callbacks caused issues. I believe it was an order of operations thing. But I can't remember.

As a related tangent, when using a "truth test" callback, I like passing it as a single argument to the assertion. Laravel will automatically inspect the type hint on the parameter to fill in the traditional first argument of the class name.