[13.x] Add ability to default queue by class type

[jackbayliss]

Currently, queue routing in Laravel requires each job, notification, or mailable to explicitly define its queue (e.g. via a $queue property or viaQueues() etc) or extend/ implement / use a class that has it defined, As a result, queue configuration often becomes repetitive and scattered across multiple classes.

I tried a basic version of this via #57712 but, Taylor rightly said the DX was off so this is a re-attempt.

This PR introduces a way to register default queue names based on a queueable object’s class, parent class, interface, or trait

This is my mind has a few use cases:

• Less repetition - no need to set the queue property or have to remember to extend something.
• Third party packages: Route package traits/classes without modifying them
• Central config: See all queue routing in one place (such as the AppServiceProvider)
• Easier environment specific queues: Different queues per environment easily

Defaults can be registered via the Queue manager:

This allows you to do:

Queue::defaultQueue(BaseMailable::class, 'mail');

// or even do multiple at once 

Queue::defaultQueues([
  SomeCustomTrait::class => 'high-priority', 
  BaseNotification::class => 'medium-priority',
  MailNotifcation::class => 'mail'
]);

You can pass in a class, interface, or trait and if the queued class is, extending / implementing or using the class it'll set the default queue to what the user has set. I don't believe it's BC as it's only called if the original queue parameter is null - and anything else ie viaQueues still takes precedent.

I've targeted 13.x as it's introduced a new trait - and feels like a big change for a patch release.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[browner12]

How would this handle things like Notifications where you can define multiple queues inside the class depending on the channel (mail, db, slack, etc) it is delivering to?

[jackbayliss]

@browner12 Thanks for your reply! 🙇 For Notifications do you mean like viaQueues? If they've defined viaQueues that will continue to take precedence, so this wouldn't override it as that's explicitly set on the class. (This is just mainly for classes where its not specifically set, so no B/C)

Details

                $queue = $notification->queue ?? $this->manager->resolveDefaultQueue($notification); // this is the new stuff it checks if they've set the default the new way

                if (method_exists($notification, 'viaQueues')) {
                    $queue = $notification->viaQueues()[$channel] ?? $queue;
                }

[shaedrich]

Is this really a default if it doesn't apply for all jobs/job types but only specific classes? Can't the base classes (e.g. abstract classes, traits, etc.) define them themselves?

If you want to see all of them, wouldn't an artisan command make more sense?

[jackbayliss]

@shaedrich Yeah, I guess they could but..

• For third-party packages, you can't modify their traits/base classes, so this lets you route them without touching vendor code
• It feels clear, so you could do it in the app service provider and it's clear whats going where - IE new people, anyone can clearly see what's going where, no picking through abstracts / traits etc.
• Environment-specific queuing becomes easy (production vs local might need different queues)

(I've added this to the main description, as I realise it wasn't the clearest 👍🏻 )

[shaedrich]

• For third-party packages, you can't modify their traits/base classes, so this lets you route them without touching vendor code

But you could extend said classes

It feels clear, so you could do it in the app service provider and it's clear whats going where - IE new people, anyone can clearly see what's going where, no picking through abstracts / traits etc.

It gets these information to one point but takes them away from the classes where the apply to. When you change these classes, you then have to think about changing the service provider as well. Just like with morph maps.

But your addition might sure be helpful to some 👍🏻

[jackbayliss]

Marking this for review to see if this might be of interest. If not, no problem. 🫡