Level 20
I tried loading your package to test, but packagist is on 0.0.3 which doesn't include the "laravel" key in composer.json for auto-discovery.
Sep 14, 2017
5
Level 1
Having trouble to set up auto-discovery for a Facade
Hi! I'm developing a small package for Laravel, and it's working fine under Laravel 5.4. I'm trying to provide the composer rules for the new auto-discovery on Laravel 5.5, but it is failing to find the required class. I wasn't able to find any in-depth documentation of the auto-discovery, but from the changes in Laravel Debugbar and from the Laracast's Video it seems that the syntax is pretty straightforward:
"extra": {
"branch-alias": {
"dev-master": "1.0-dev"
},
"laravel": {
"providers": [
"AndreChalom\\LaravelMultiselect\\MultiselectServiceProvider"
],
"aliases": {
"Multiselect": "AndreChalom\\LaravelMultiselect\\MultiselectFacade"
}
}
},
The MultiselectFacade and MultiselectServiceProvider are working fine when explicitly included in the config/app.php file, and I can use the {!! Multiselect::select(...) !!} just fine in my blade templates. I can also comment out the "MultiselectServiceProvider" line and everything works fine - the provider is auto-discovered and registers the Multiselect service. Yay!
However, if I delete the "MultiselectFacade" line from the config/app.php, relying on the auto-discovery, suddenly the application fails with "Class 'Multiselect' not found". What I may be missing? How can I debug this?
Level 1
Hello, clay. Thanks for your input! You can load the "dev-master" from packagist, which has the required composer directives.
Level 47
try running
php artisan clear
composer update
it will generate a new bootstrap/cache/packages.php file
it should work for you
1 like
Level 1
That did it! Thanks so much and sorry for the late answer :)
Level 9
I tried this to reset the cached aliases that I changed in a package I was developing. It kept on picking up the old alias name, no matter what I did, and even when there was no trace of the old alias name in any PHP or JSON file in the application.
Turned it out it was an artisan queue:work process that was holding onto the old settings. This is on PHP 7.2, which does some fancy inter-process cacheing of data automatically. I can not see how that process could have affected the composer update otherwise. Once I stopped that queue worker, the clear+update worked a treat.
Just adding this in case anyone else is sat there scratching their head for an hour over why changes aren't being recognised.
Please or to participate in this conversation.