Use a safer auto-discover default

[ragingdave]

Currently settings auto-discover will attempt to discover all classes in the app path. This includes things like a Telescope provider that's only intended to be accessed in a dev/testing environment. This chewed up about an hour or so during a production release. Luckily no downtime as we are using zero downtime deployment methods and this was caught before any damage, but still wasn't caught until prod.

Perhaps a more sane default would be, albeit opinionated, but using app\Settings as a default discover path? I would imagine most apps would warrant a structure such as that, and would prevent being blindsided by this broad auto-discover logic.

[rubenvanassche]

Hi @ragingdave,

It is possible to set the paths where classes are auto discovered in settings.php auto_discover_settings. How did the the Telescope provider block your site?

We're not seeing such problems. As for the default of App/Settings all our projects do not follow this default since we're using domains to structure our code. So I think we should keep the default as it is.

[rubenvanassche]

Can we automatically remove this service provider? Please correct me here:

• you have a TelescopeServiceProvider which extends from a BaseTelescopeServiceProvider
• this BaseTelescopeServiceProvider is not available in production
• that's why the discoverer crashes because it cannot find the BaseTelescopeServiceProvider
• and the auto discoverer fails

Is it possible to just skip that class by catching the exception?

[ragingdave]

Yes you are correct there.
It is a class not found exception so potentially could catch it, but that feels a little invasive to basically just ignore classes where a parent class doesn't exist. This "hiding" might introduce a different equally hard to debug error in it's own right for certain situations.

[rubenvanassche]

Hmm I don't really see that as a problem, since we're only checking for classes that are a subclass of the Settings class, if there's a case where that class doesn't exist then something went really really wrong 😄

Is the auto discoverer crashing here?

laravel-settings/src/Support/DiscoverSettings.php

Line 64 in 37aa95a

->filter(fn (string $settingsClass) => is_subclass_of($settingsClass, Settings::class))

We could just add a try ... catch around that block and ignore it when it fails.

[ragingdave]

Yep that is exactly where it's failing. I did try a local mod with a try catch around that and it works but only if you are catching Throwable.

[rubenvanassche]

Added this functionality to 2.1.2, thanks for your input!