Composer Update failed -- out of memory
Check the Composer's troubleshooting wiki, especially the memory limit errors section.
For instance, by running the composer like this:
php -d memory_limit=-1 `which composer` update
I get no error anymore. So it is probably an insufficient memory issue that can be solved inline, without altering your default PHP configuration.
What the command above does is that it sets the PHP CLI memory limit to "unlimited" (ie. -1) and then it runs the inline composer update command.
Please note that instead of `which composer` you should probably use the real path of your composer.phar PHP script. The which composer written inline (like in my example above) will be inline solved to your composer.phar full path (you may use whatever form you like).
Note: in case both the physical and virtual memory is exceeded the above solution might fail as well. If that is the case then the obvious solution would be to increase your system's virtual memory then try again.
The only thing that solve my problem was doing this:
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1
REF: COMPOSER TROUBLESHOOTING
From my experience, memory errors from composer usually means it is spending too much memory looking for the right combinations of packages to install, especially the version constraints are not specific enough. For example, ^5.2.4 matches 5.3 to 5.3.29, 5.4 to 5.4.45, etc. For each specific version and permutation, composer has to get the package's dependencies to check if all the constraints are met. This is usually when the memory consumption gets huge.
Once the versions have been figured out, the installation phase uses much less memory. The resolved versions for each package are also stored in a composer.lock file so that the specific permutation installed can be replicated in other environments. And this is the potential solution to your issue: run composer update in your dev machine (which should have enough memory), deploy the updated composer.lock, and run composer install on the server.
Composer install will always reference the existing composer.lock for the versions to install for each package, and thus should seldom run into memory issues.
For a reference on how to express version constraints in composer.json, check out https://getcomposer.org/doc/articles/versions.md
Solved by deleting the whole vendor folder, and then doing the composer update again, and it works... somehow. I don't even understand :v