[12.x] Fix support for adding custom observable events from traits

[willrowe]

This delays the observe call in the boot method for the HasEvents trait until after the model has finished booting so that any custom events registered by other traits are available to be matched up to observer class methods.

This fixes the initial issue that was discussed in #53607

[willrowe]

There are some funky issues with the tests and listening for the booted event. I will have to take another look on Monday. Setting as draft for now.

[willrowe]

The complexity introduced to testing by using the booted event in order to boot the events was not acceptable. When I was initially adding that listener it did give me pause since events relying on the event dispatcher seemed brittle.

A new whenBooted static method has been added to models, which can be used by traits to defer until after all other traits have been booted.

[azzazkhan]

@willrowe I'm not sure, but I guess this broke the functionality of defining magic methods on traits for Eloquent models, e.g., boot{TraitName}.

[willrowe]

@azzazkhan how so?

[tom-on-the-internet]

Leaving a comment in case this helps someone else with their Laravel 12 upgrade.

This change makes sense and it solves another issue.

But, when upgrading to Laravel 12, this change caused a change in our business logic.

We expect the event hooks set by ObservedBy to run before event hooks set by a bootable Trait.

Previously, in our trait, we had

    protected static function bootMyTrait(): void
    {
        static::deleting(function ($model): void {
            // logic here
        });
    }

With this change, the above is now registered before our ObservedBy hooks. So, our trait's deleting runs first, which is not what we want.

To fix this, I've used the new static::whenBooted

    protected static function bootMyTrait(): void
    {
        static::whenBooted(
            fn () => static::deleting(function ($model): void {
                // logic here
            })
        );
    }

Hopefully this helps someone.

[willrowe]

@tom-on-the-internet that is something I did not think of and makes this a bit of a breaking change. I'm wondering if it would be worth proxying registerModelEvent through whenBooted to restore the original order? I guess it depends on if it makes more sense for a specific order or for it to be intentionally unspecified so order should not be relied upon?

[willrowe]

On second thought, it's probably best to leave it as-is. It does not look like the boot order of traits is specified, so it shouldn't be relied upon.