Laravel-modules: Changing the order value doesn't affect order of routes

[oleaass]

Package Version: 7.1.0

Not sure if this is a bug, or if it's me doing something wrong. But I cannot seem to get the routes to load in the order I want.

The module:list command show's that Page has order value 9999

> artisan module:list
+-------+---------+-------+---------------------+
| Name  | Status  | Order | Path                |
+-------+---------+-------+---------------------+
| Core  | Enabled | 0     | /****/Modules/Core  |
| File  | Enabled | 0     | /****/Modules/File  |
| Page  | Enabled | 9999  | /****/Modules/Page  |
| Place | Enabled | 0     | /****/Modules/Place |
+-------+---------+-------+---------------------+

but from the image below it's clear that the routes from Page is loaded before Place, which causes the catchall route in Page to override everything in Place

I have also tried to change the order value for the File module to a number higher than 9999, but no changes to route order.

When dumping the value from FileRepository::getOrdered() the modules are listed in the correct order.

[oleaass]

The more I look into this, the more confused I get..

I now added a var_dump() in each of the modules register() method

string(31) "CoreServiceProvider::register()"
string(31) "FileServiceProvider::register()"
string(31) "PageServiceProvider::register()"
string(32) "PlaceServiceProvider::register()"

So Page is triggered before Place. But when I add this

dd($this->getOrdered());

to FileRepository::register() I get this

array:4 [▼
  "Core" => Nwidart\Modules\Laravel\Module {#2782 ▶}
  "File" => Nwidart\Modules\Laravel\Module {#2794 ▶}
  "Place" => Nwidart\Modules\Laravel\Module {#2802 ▶}
  "Page" => Nwidart\Modules\Laravel\Module {#2798 ▶}
]

Update
I added a static $count = 0; to Laravel\LaravelFileRepository::createModule() and this reported that the method was called 112 times? And the modules are created based on position in the filesystem, not from ordered. This makes sense since it's the first time the application knows about the module. But it does not make sense that it's called that many times for only 4 modules.

[nWidart]

Hm this is weird indeed, the modules should be booted using the ordered method as you mentioned.

[oleaass]

That's what I thought. Do you have any debugging tips that I can try? Not too familiar with the internals of this package, so now I'm just adding var_dumps spitting out name of class and method to see what's getting triggered

[nWidart]

If you have xdebug setup you can put breakpoints and go from there.
Otherwise var_dump's are another way.

[oleaass]

@nWidart I have found the issue. It's caused by Laravel's auto discover. Since the providers are listed in the composer.json, Laravel autodetects it and they are actually loaded in before even your package is triggered.

Solution to the issue, remove the provider from the module's composer.json and run composer update

[nWidart]

Ooh that's interesting. Very good to know, thanks!

[oleaass]

Glad I could help sort it out! Did a quick writeup of the issue - Laravel modules order not being obeyed

[nWidart]

Thanks! Very interesting.
I wonder if the modules shouldn't have that part in their composer file because of it.

[oleaass]

I don't think they should. This probably also means that you won't be able to disable modules.

[oleaass]

Closing this issue since it's solved by #996

[samerzaki]

@oleaass hello, I tried your way by deleting (serviceProvider) from each module composer.json but it didn't work.
laravel still load modules instead of nWidart
the only solution that worked was writing the package name in main composer.json (dont-discover)
but that need to write all packages names
so, any solutions ?