Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
It's too bad that "Composer" isn't a category/topic on here because I feel like a good percentage of the time, the issue has to do with Composer, not Laravel.
Anyhow, I have this head scratcher here. I have two vanilla Laravel 7 projects going, let's call them A and B.
Project B is literally bare bones, as in, I just created it from scratch using composer create-project.
Project A I started a week ago. The only thing I've done so far on project A is to try to reverse engineer a large remote database to migrations, seeds and models, using 3 of my favorite --require-dev extensions.
The remote database has (yes, not a typo) 700 tables and another 1,200 views. The existence of the massive folder full of files in database/migrations and database/seeds is the only difference I can see between the two projects.
The psr-4 and classmap sections of composer.json are the same on both projects.
When I do a composer dump-autoload, everything works fine on both projects, meaning the terminal output looks the same and there are no errors.
php artisan migrate:fresh --seed works on the tiny shell project B.
php artisan migrate works on project A.
php artisan db:seed does not work on project A due to:
Illuminate\Contracts\Container\BindingResolutionException
Target class [DatabaseSeeder] does not exist.
For the life of me, I cannot figure out why composer is refusing to include the DatabaseSeeder.php file in vendor/composer/autoload_classmap or vendor/composer/autoload_static
So I manually add it, just to see what's going on. Upon inspection, I am seeing that
root@37dd7e2b7563:/var/www/vhosts/ProjectA$ cat vendor/composer/autoload_classmap.php | grep Database | grep Seeder | wc -l
551
root@37dd7e2b7563:/var/www/vhosts/ProjectA$ ls -la database/seeds/ | wc -l
1119
about half of the database seeders actually made it into composer's dump autoload files, and I am at a loss to explain it.
I ran it like this, too:
php -d memory_limit=-1 composer.phar dump-autoload
thinking it could be memory related (silent issue) but the same thing is happening.
Composer version 2.0.8 2020-12-03 17:20:38
Developing on Windows using a custom Docker setup (nginx, PHP-fpm)
PHP Version 7.4
Any ideas? I am stumped.
I tried using Composer 1.10.19 as well, and after doing a full rm -rf vendor, composer clearcache and composer install, I believe composer is working now, but Laravel is still unable to db:seed as it is still unable to find the DatabaseSeeder.php class. Still getting:
Target class [DatabaseSeeder] does not exist.
How does this make any sense? When I try running php artisan db:seed it fails with an inability to resolve the class out of the container:
Illuminate\Contracts\Container\BindingResolutionException
Target class [DatabaseSeeder] does not exist.
at vendor/laravel/framework/src/Illuminate/Container/Container.php:811
807|
808| try {
809| $reflector = new ReflectionClass($concrete);
810| } catch (ReflectionException $e) {
> 811| throw new BindingResolutionException("Target class [$concrete] does not exist.", 0, $e);
812| }
Yet - I can launch a tinker session and find the DatabaseSeeder class without any issue:
root@5bb8d1bffde0:/var/www/vhosts/ProjectA$ php artisan tinker
Psy Shell v0.10.6 (PHP 7.4.14 — cli) by Justin Hileman
>>> $reflector = new ReflectionClass('DatabaseSeeder')
[!] Aliasing 'DatabaseSeeder' to 'Database\Seeders\DatabaseSeeder' for this Tinker session.
=> ReflectionClass {#3359
+name: "Database\Seeders\DatabaseSeeder",
extends: "Illuminate\Database\Seeder",
My first thought is that since you're using Docker, you need to be running ALL your artisan commands inside the container in order to avoid composer from using the directories from your host machine inside the container.
I remember we ran in to that a lot on our other projects.
inside your container, run your composer dump-autoload, php artisan config:clear since it's just a dev environment and you don't need the speed on load right now, this also prevents you from having to run the cache command every time something changes.
If there's still issues at this point, just make sure the container user has permissions to all the files in the directories since you were probably running commands from your host and windows could easily be messing up permissions too. Also Composer has an environment variable in Docker that you might need to set in your .env file for docker, COMPOSE_CONVERT_WINDOWS_PATHS=1 which will require you rebuild your docker container.
Hope this helps
I am pretty convinced these issues are related to Docker for Windows.
I have had some issues with it in the past, where all of a sudden the directories go missing. It seems like this is just an inability of DFW to properly read/see all the files in Windows. I don't know why it seems consistently inconsistent.
I tried running my project on the Laradock container, and got the same result.
I cannot be the only person to run into this... but the problem appears to be 100% related to Docker for Windows.
I ported the entire project to another machine running Ubuntu with Docker, did all the same steps and it works fine.
Also trying it on straight up Windows, seems to work fine. There seems to be silent failing of file list when directories are large, in Docker for Windows. Such a shame.
Here is a related open issue already filed against Composer, but the thread TL;DR is they can't fix it due to the issue is with the virtual file system.
Please or to participate in this conversation.