The same issue, the same environment and framework.
PHP 7.0.11, Composer 1.2.1

Discussion about problem by other people https://laracasts.com/discuss/channels/general-discussion/composer-generating-autoload-files-fails

The best solution for now - downgrading to Composer 1.2.0

I'll try to downgrade it but how can I do that?

@Rufflesaurus , just composer self-update 1.2.0
Or you can replace your composer bin with https://getcomposer.org/download/1.2.0/composer.phar

Do you have a way to reproduce this without artisan? I'm not going to install laravel global plugins just to get this working. If you do not have any other way to reproduce this, then I think we can conclude that this is not a composer bug, but a laravel bug instead.

I think it's hard to reproduce this problem because it only happens from time to time, usually when the composer dump-autoload -o is running. It also happens when I install a new package / do an update for new packages.

It's ok for now, I'll report back if it happens again.

OK closing this for now but please come back to us with details if you find a way to reproduce it reliably. Downgrading to 1.2.0 is not a solution btw, if downgrading really helps, then we need to figure out what broke in 1.2.1 and fix it.

I can reproduce an empty autoload_classmap.php file using

{
    "require": {
          "authorizenet/authorizenet": "~1.8"
    }
}

for composer.php
and Composer v1.2.1 and PHP 7.0.8

@coldlamper what version do you get installed? Because 1.8.0 has no autoload definitions at all, so that doesn't mean anything.

I think it's 1.8.9

I think it's 1.8.9

It would be nice if you could take the time to check and confirm. Cause the difference is quite significant.

Sorry it is installing 1.8.0. I believe it should be installing 1.8.9, correct?

1.8.9 has a bunch of requirements like it needs ext-xmlwriter and ext-simplexml, maybe you don't have those so it is downgrading to 1.8.0 which does not have the requirements. Try requiring 1.8.9 explicitly and it should tell you why it is not installable.

Using "authorizenet/authorizenet": "1.8.9"

Problem 1
    - Installation request for authorizenet/authorizenet 1.8.3.3 -> satisfiable by authorizenet/authorizenet[1.8.3.3].
    - authorizenet/authorizenet 1.8.3.3 requires php ~5.3 -> your PHP version (7.0.8) does not satisfy that requirement.

next step: contact the authorizenet maintainers to ask them to allow installing their package on PHP 7 (their PHP requirement tells composer that it cannot be used on PHP 7)

For now you can get around this by using the --ignore-platform-reqs flag.

It looks like the problem is back once I ran composer update to update the packages. Before that, I tried running composer dump-autoload -o just to see if it will fail again, but it was magically fixed for some reason.

I didn't use any commands for a few days and just before I started using them again I ran composer update and something brought the problem back.

Still trying to figure out what might be causing the problem but I have a hard time reproducing it so you can test it on your own.

I had the same error. I think it is not related to composer.

My configuration is: Windows host, vagrant with Debian quest and nfs sharing enabled, composer 1.2.1.
I debugged this and noticed that composer in src/Composer/Autoload/AutoloadGenerator.php:273 wants to save content to existing file autoload_classmap.php:

file_put_contents($targetDir.'/autoload_classmap.php', $classmapFile);

After this operation (called with success) content of this file is still empty. I removed this file (vendor/composer/autoload_classmap.php) and call again composer.phar dump-autoload. File was created with content and problem was solved.

I think problem is related to permissions of this file or problems with sharing files between host -> quest in vagrant... I hope I will help someone :)

@jural I tried deleting all of the autoload files inside the composer folder and running composer dump-autoload -o as you suggested but the problem is still there.

I can confirm this problem, multiple of our developers faced it within the last weeks. Sometimes we could solve it by deleting the autoload_classmap.php file, sometimes by reloading Vagrant, sometimes we couldn't get it working at all. It's not a Laravel problem, it's caused by Vagrant on Windows, specifically by the winnfsd/vagrant-winnfsd plugin. The file_put_contents in src/Composer/Autoload/AutoloadGenerator.php:273 mentioned by @jural does actually work, it returns the number of written bytes like expected. However, the file is still empty after the write operation finishes. This confirms the whole problem being related to the underlying file system. If you configure composer to keep the vendor dir outside of the scope managed by winnfsd ("vendor-dir": "~/composer/"), everything works fine. The winnfsd plugin is known for being quite buggy in general, so I don't think something in composer can be done to solve this problem.

Not a vagrant problem, I just got this running native on Linux and PHP 7.1.

In my case (using Homestead) this seems to be fixed by removing type: "nfs" from the folders section in Homestead.yaml.

@andrei930 Yes that solves the problem, but without NFS the VM is significantly slower, so that's not really a solution.

Apparently I was using an outdated version of vagrant-winnfsd. For me it's fixed by updating to the latest version (1.3.1).
Edit: Nevermind, it still fails after a while (?). A workaround is to halt the machine, kill the NFS server and start the vagrant again.

Anybody found a "proper" solution for this? Halting / killing is kind of hacky.

You can try to use SMB instead of NFS, I am not really aware of the consequences though. Otherwise, I am happy to share the script we ended up with you guys:

#!/usr/bin/env bash

vagrant halt
cmd "/C TASKKILL /IM winnfsd.exe /F";
vagrant up
vagrant ssh

Just put that in a bash file on your host machine and execute it once NFS crashed.
Still a hackish solution, but what shall we do :)

@spiritix that's exactly what we're doing as well, but I thought maybe winnfsd developers came up with a better solution.
Alternative option would be composer dumpautoload (without optimize flag).
It's a clearly NFS mount problem (I've tried experimenting with NFS mount option, which helped a little), as it looks like it runs out of memory?
Non-NFS mount is not an option I think, it would be the same as downgrading to Windows 98 just because Windows 10 freezes once in a month.

@YOzaz Already reported that to the winnfsd developers (winnfsd/vagrant-winnfsd#104), maybe you could file an issue as well.

@spiritix Damn, I also encountered this problem, based on your recommended solution, is in the local new bash file, the script writing, run it, as I so, operation is still running NFS.

@szlwl what?

Had the exact same problem.

Windows 10, Version 1803, Build 17134.228
Vagrant 2.1.0
VirtualBox 5.2.12
WinNFSd 1.3.1
Laravel Homestead (not sure about the version, probably 7.6, but it shouldn't really matter).

Not using NFS isn't really a solution for me, as it increases page load times from ~2 sec to ~10 sec, sometimes even more.

Seems to be solved by setting these NFS mount options:

mount_options: ['rw,vers=3,udp,nolock,actimeo=2']

I hear that UDP isn't ideal, but it works; on TCP the VM would just freeze on me after ~15 minutes of inactivity, never to recover.

BTW, another and probably related issue, after running gulp three and more times to minimize the JavaScript sources, I got a 0 byte file as a result along with a NFS server error No such file or directory IO as mentioned here: winnfsd/vagrant-winnfsd#104 (comment) and only reloading vagrant & the NFS server solved it. Turned out to be an issue with Windows Defender, probably an exclusive file lock / race condition issue.

Excluding the whole synchronized folder from the Windows Defender "workspace" seems to do the trick, at least up till now it has – might work in this case for you too.

Also, since then I updated all the tools to their current versions (Vagrant 2.1.2, VirtualBox 5.2.16, WinNFSd 1.4.0, Homestead 7.14.2) and now I'm having zero issues, so I recommend updating everything too.