So I write these little tech snippets mostly as a personal journal for my future self. Anyway, got caught again at work by a weird situation where dev and test/prod environments differed. Well, not really, but kind of. What?
I deployed our main app last month after upgrading it to Laravel 5 and all seemed to be working fine. Was working fine on dev too. Fast forward to today and my tests break on dev with an error about not finding a couple of namespaced classes. Hour or two of sleuthing ensued.
The gist? By default Laravel runs the command “php artisan optimize” after install and update. This command runs “composer dump-autoload –optimize” behind the scenes. That Composer command generates a huge class map of all of your classes, even your PSR classes… unless you tell it not to (which you can do through the Laravel command by passing the “psr” option).
So on dev, I regularly make changes, add/remove classes, and run “composer dump-autoload” after I do. Notice that command I run manually does not contain the “–optimize” option. Thus the huge class map is not created. Thus the two classes that are somewhat non-standard in their location on disk are not found by the PSR autoloader. Thus the error.
I’m not sure why “composer dump-autoload –optimize” can find and map those two classes just fine, but the actual PSR autoload implementation (without a classmap), cannot find those two classes. But it can’t. And it breaks.
So as a final result, I need to remember to add the –optimize flag when I run dump-autoload on dev (because that’s what Laravel does on test/prod). Or I could move those two classes somewhere else, or add their location to the “classmap” key in my composer.json.
Clear as crystal?
