L5 with PSR-4 package

What errors are you getting from Artisan? Is it one of the post-update commands?

If you're changing paths or files or anything like that, it's better to remove the packages you're changing from composer/config, update, then add the new ones.

Artisan shouldn't error because of composer, so remove the entries from providers and aliases for your package, run php artisan clear-compiled then run composer update again. That should hopefully work and once that's done, add your providers and aliases entries back.

Let me know how you go!

@beaverusiv I suppose it is not composer issue, but just artisan one. And mind that artisan is run on post-update event.

It's pretty common, however composer itself runs update and throws error afterwards. Then you just do composer dump-autoload && artisan clear-compiled && artisan optimize

PHP Fatal error:  Class 'Beaverusiv\Permissions\Models\Group' not found in /home/vagrant/Code/beaverusivbase/vendor/beaverusiv/permissions/src/Permissions.php on line 11
PHP Stack trace:
PHP   1. {main}() /home/vagrant/Code/beaverusivbase/artisan:0

I was hoping there was a way to make composer dump-autoload always run with the -o flag so I wouldn't have to intervene everytime.

Yes, I have had problems before where I changed some code and Artisan complained (because it was trying to unserialise an object from cache that had changed). This is different. If I run update without anything happening on Composer's side it still errors out.

@beaverusiv I suppose you could just add it to the post-update commands:

"post-update-cmd": [
   "composer dump-autoload -o",
   "php artisan clear-compiled",
   "php artisan optimize"
],

@beaverusiv I thought it was just me. I posted a long discovery breakdown of the problem https://laracasts.com/discuss/channels/general-discussion/upgrading-to-l5-and-getting-class-not-found-on-composer-update/?page=3 . For some weird reason if the app writes the services.json file vs. artisan it all works fine. It is screwing up the sequence of writes in services.

btw, it fails silently so the only way you know is class not found. In my case it is my view composer.

If I run artisan optimize this is what it writes to services.json. This fails silently so that my translator decorator and view composer are not bound to the IoC

"deferred": {
...
        // note this is my own SP that extends the Laravel Translator SP
    "translator": "App\\Administrate\\Providers\\TranslatorServiceProvider",
    "translation.loader": "App\\Administrate\\Providers\\TranslatorServiceProvider",
...
}

"when": {
    ...
        // 
    "App\\Administrate\\Providers\\TranslatorServiceProvider": [],  
    ...
}

However, if I let the provider touch the services.json this is how it writes it. This works and the app runs fine. As you cane see it is now eager loading my SP and deferred the Laravel SP that I'm extending.

"eager"{
    ...
    "App\\Administrate\\Providers\\TranslatorServiceProvider",
    ...
}

"deferred": {
...
    // notice these are the Laravel Translators. 
    "translator": "Illuminate\\Translation\\TranslationServiceProvider",
    "translation.loader": "Illuminate\\Translation\\TranslationServiceProvider",

}

I battled with this for 2 days last week assuming it was me being stupid. Nolros has done a great job here. I haven't had time yet to try it out yet - been busy with boring stuff :o)

@vincej lol .. btw there are a number of formal artisan bugs reported so I think it is a legit issue. For now now Jarek's approach is simple and works.

@nolros many thanks again - you are a ROCKSTAR !