Registering observers with the ObservedBy attribute is not tracked by event:list command

[illambo]

Laravel Version

11.33.2

PHP Version

8.2.24

Database Driver & Version

No response

Description

Hi, I noticed that when I register an observers with the ObservedBy attribute is not tracked by event:list command while via observe method in an AppServiceProvider this is appropriately tracked.

Steps To Reproduce

• Create a model with an Observer
• Run php artisan event:list command
• Check the different behavior based on the register mode

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[ashraful1971]

The issue occurs because PHP attributes like ObservedBy are inspected at runtime. Observers registered using attributes are resolved only when the corresponding model is bootstrapped. However, the php artisan event:list command does not bootstrap models, so their observers are not resolved, and related events do not appear in the list.

To include these in php artisan event:list, a mechanism is needed to discover and bootstrap all models in the application. This could be achieved by:

• Automatically scanning directories (e.g., app/Models) to locate all model classes.
• Explicitly defining a model registry (e.g., in a models.php config file).

[illambo]

I also noticed in this discuss #53607 another behavior that differs.

[ashraful1971]

I also noticed in this discuss #53607 another behavior that differs.

Yeah. Same issue. Adding new trait in a model wont make any effect until the model is bootstrapped.

[messikiller]

The issue occurs because PHP attributes like ObservedBy are inspected at runtime. Observers registered using attributes are resolved only when the corresponding model is bootstrapped. However, the php artisan event:list command does not bootstrap models, so their observers are not resolved, and related events do not appear in the list.

To include these in php artisan event:list, a mechanism is needed to discover and bootstrap all models in the application. This could be achieved by:

• Automatically scanning directories (e.g., app/Models) to locate all model classes.
• Explicitly defining a model registry (e.g., in a models.php config file).

It's true, but seems hard to fix the issue ...

[ashraful1971]

The issue occurs because PHP attributes like ObservedBy are inspected at runtime. Observers registered using attributes are resolved only when the corresponding model is bootstrapped. However, the php artisan event:list command does not bootstrap models, so their observers are not resolved, and related events do not appear in the list.
To include these in php artisan event:list, a mechanism is needed to discover and bootstrap all models in the application. This could be achieved by:

• Automatically scanning directories (e.g., app/Models) to locate all model classes.
• Explicitly defining a model registry (e.g., in a models.php config file).

It's true, but seems hard to fix the issue ...

Right, I suggested two solutions, but fixing it might feel like more hassle than it’s worth—still, if someone needs it to work, they could give them a shot.

[ghostal]

To include these in php artisan event:list, a mechanism is needed to discover and bootstrap all models in the application. This could be achieved by:

• Automatically scanning directories (e.g., app/Models) to locate all model classes.
• Explicitly defining a model registry (e.g., in a models.php config file).

The second option here sounds like it would be annoying and laborious for developers using Laravel, and an auto-discovery convention similar to the one employed with event listeners would be far preferable.

So as not to negatively affect performance though, implementing that would also necessitate implementing a caching mechanism (again, as is the case with event listeners) so that artisan optimize could prevent production systems from trawling the filesystem on every request.

It looks like it would be fairly straightforward to implement both of those features though, with some modifications to Illuminate\Foundation\Support\Providers\EventServiceProvider::register(), some additional methods similar to the Illuminate\Foundation\Support\Providers\EventServiceProvider::getEvents() sequence, and a Illuminate\Foundation\Events\DiscoverObservers class similar to Illuminate\Foundation\Events\DiscoverEvents.

I'd be interested in working on this if it sounds like something the Laravel team would be happy to merge.

[illambo]

imho it would be important to take into account and try to align also the different behaviors of #53607