When I’m working on a feature or refactor, I often leave @todo comments to remain in flow and deal with other points later.

I don’t mind committing them to my feature branch, as long as I work them away before merging in.

On large branches, it can be easy to forget about that todo I left in there a few days ago.

class PodcastController
{
public function process(Podcast $podcast): void
{
$podcast->process();
// @todo Broadcast event to trigger webhooks
return $podcast;
}

Before I merge, I pipe git diff into a grep call to scan for changes that include @todo.

git --no-pager diff main..feature-branch | grep -i "^\+[^$]*@todo"

+ // @todo Broadcast event to trigger webhooks

This one’s permanently stored in my Pinboard — a conversation I had this morning triggered a re-read.

“A user is only part of one team”. Until we decide to add multi-team support, and the $user->team BelongsTo relation suddenly needs to be replaced in 50 places.

Golden advice from swyx:

It is a LOT easier to scale code from a cardinality of 2 to 3 than it is to refactor from a cardinality of 1 to 2.

In Laravel, you can register a class as a singleton to always resolve the same object.

However, you might want to build another instance of the class. You could manually construct the class without Laravel’s container, but if it has a bunch of dependencies it can be tedious.

With the build method, Laravel won’t resolve a registered instance of the class, but build a new one with the container.

// AppServiceProvider::register()
$this->app->singleton(MastodonClient::class);

// Resolve the singleton instance from the container
$mastodon = resolve(MastodonClient::class);
// Build a new instance
$anotherMastodon = app()->build(MastodonClient::class);

This can be useful when a Laravel package registers a class as a singleton but you need another instance.

Freek shares a few patterns we employ to let developers override behaviour in our packages.

One of the ways we keep maintenance burden low is by making our packages customizable. In this blog post, I’d like to cover some of our best tips to make a Laravel package easy to customize. Some of these tips will apply to regular projects as well.

Rauno Freiberg (designer at Vercel) shares his web guidelines for web interfaces. A few that stood out for me:

• Inputs should be wrapped with a <form> to submit by pressing Enter
• Interactive elements should disable user-select for inner content
• Actions that are frequent and low in novelty should avoid extraneous animations

Read them all on Rauno’s (beautiful) website, and check out the Craft section while you’re there.