In Laravel, package discovery is the process by which Laravel automatically registers service providers and aliases for your packages. However, controlling the order in which packages are loaded can be important if one package depends on another.
To control the loading order of your custom packages, you can manually register the service providers in the config/app.php file instead of relying on automatic package discovery. Here’s how you can do it:
Disable Package Discovery for Your Packages:
First, you need to disable automatic package discovery for your custom packages. You can do this by adding the dont-discover key in your composer.json file:
Replace vendor/package-one and vendor/package-two with the actual names of your packages.
Manually Register Service Providers:
Next, manually register the service providers in the config/app.php file. You can control the order by the sequence in which you list them in the providers array:
'providers' => [
// Other Laravel Service Providers
// Custom Package Service Providers
Vendor\PackageOne\PackageOneServiceProvider::class,
Vendor\PackageTwo\PackageTwoServiceProvider::class,
],
Ensure that PackageOneServiceProvider is listed before PackageTwoServiceProvider if PackageTwo depends on PackageOne.
By following these steps, you can control the order in which your custom packages are loaded in a Laravel application.
@Snapey This is unrelated to the original issue but one around package conflicts.
Two packages seem to have a conflict purely based on the order in which they are bootstrapped. Package 1 will add a schedule into the Illuminate\Console\Scheduling\Schedule class and is run first. Package 2 will add a macro for use within app/Console/Kernel.php to apply to scheduling jobs. In this case, a macro to skip based on a feature flag.
Using the macro within app/Console/Kernel.php throws an exception because when Package 1 is trying to boot there is no macro registered when creating the Schedule. Bootstrapping Package 2 first gives access to that macro to be used and fixes this issue.
In this case, is it possible to re-order? Since these are both vendor packages there is no capability to alter these service providers.
@mbradley As long as its bootstrapped from the service provider in package 2, then order does not matter. Laravel will load both before it runs any of your own code
@Sinnbeck Through debugging this issue a call to $this->app->make(Schedule::class) within the service provider of Package 1 did throw an exception for an undefined method when it was being booted. This halted any further execution of the array_walk found within vendor/laravel/framework/src/Illuminate/Foundation/Application::boot and meant that no further service providers were called.
Unless the service provider from Package 2 was manually booted from the register method of the AppServiceProvider then this issue persisted, but i'm always open to hear about better ways to deal with this specific issue.
