Ensure modules are registered in register phase

[tareq-alqadi]

Moved module registration to the register() method to ensure that module service providers are loaded early and take their proper place in the Laravel lifecycle. Previously, module service providers were being registered during the boot() phase, which caused their register() methods to run too late — during the boot stage — leading to incorrect and unintended behavior.

Additionally, removed the cacheManager dependency from the FileRepository, as it is not available in the register() phase and was not being used.

[dcblogdev]

@alissn can I get your opinion on this PR

[alissn]

Hi,
@dcblogdev That sounds logical. Moving the module registration to the register method is a good approach.

thanks @tareq-alqadi

[tareq-alqadi]

Hi,
If you’re looking for a practical example of how this PR is useful:
In FilamentPHP, when you register an admin panel inside a module, you add the panel configuration in the register() method. Later, the panel is registered using that configuration when resolving the PanelRegistry::class binding, which happens before or early during the booting phase — definitely before module service providers run.

So, if module service providers are registered in boot(), the panel configuration won’t exist yet because those providers haven’t run.

This is just one example. Any package relying on similar resolution timing (like Filament) will face the same issue. Without aligning this package’s lifecycle properly, it won’t work correctly.

[alissn]

Hi @tareq-alqadi,

After applying this change, I'm encountering the following error when loading module routes:

It seems that Laravel Permission registers its macros in the boot method.

Do you have any idea how to fix this?
Should the change be made in the project itself or in the Laravel Permission package?

[tareq-alqadi]

Hi @alissn

This happens because the module routes are loaded before the macros are registered, even though the routes are loaded inside a booted closure.

But there are two types of booted behavior in Laravel: one runs immediately after each service provider's boot() method, and the other runs after the entire application and all service providers have finished booting.

The RouteServiceProvider in the module boots and its booted callback runs immediately before the PermissionServiceProvider boots and registers the macros—unlike Laravel's core RouteServiceProvider, which runs last, after the macros have been registered.

To solve the problem, you have a couple of options:

1. Move the registration of the RouteServiceProvider from the register method to the boot method.

2. Create a custom RouteServiceProvider for the package that extends the core one, ensuring that routes are loaded after the entire application has fully booted, not immediately after the service provider is loaded.
   

3. Avoid using macros in routes; instead, use middleware like can:some-ability.

4. Submit a PR to the Laravel Permissions package to register their routes in the register method instead of boot. However, this might not be accepted since macros are documented to be registered in the boot method, and other packages may face the same issue.

I hope this helps you.