composer posts

Homebrew `composer` 2.6.x failing

For some reason, the Homebrew version of composer hasn’t been working recently, either 2.6.1 or 2.6.2. So I’ve manually grabbed the phar from and replaced the file it was getting. I’m running the latest MacOS and up to date Homebrew, PHP, and Composer on an Intel Macbook Air. When I would run composer, I would get an exception

Continue reading post "Homebrew `composer` 2.6.x failing"

Swap file for composer out of memory problems

PHP’s defacto package manager, composer, has long required large amounts of memory to do updates for larger projects, often more than servers or virtual machines have. The script will die with an out of memory error, or more recently, the simple message “Killed”, and do no work in these situations. The normal procedure is to develop locally, deploy local lock file (composer.lock) to the server, and run composer install instead of update. But I’ve recently moved to doing most of my development in VMs, so I have had to work around this problem to get things installed or updated. A swap file is the solution for Linux machines provided in the official docs and expanded in a StackOverflow answer.

Continue reading post "Swap file for composer out of memory problems"

Working with Composer ‘scripts’ and ‘extra’ from Non-Root Package

The goal of my Symfony StandardEditionBundle is to capture as much of the logic and configuration of the Symfony Standard Edition as possible to make it easy to upgrade between versions with as little modification to the in place application as possible. Among things I wanted to try to get into the bundle was as much as possible of the composer configuration file. It contains a ‘scripts’ key of scripts or functions from packages that are supposed to be run upon install / update by composer to set up the application (for instance, one script walks you through creating the ‘parameters.yml’ configuration file). There is also an ‘extra’ key used as configuration for these scripts.


Composer only allows the ‘scripts’ to be defined in the root ‘composer.json’, ie the one in your application. The idea is that scripts will only run that the owner has explicitly given permission to, and thus trust. This prevented me from putting them directly in my bundle’s ‘composer.json’, as they would be ignored. My solution was to create functions in my bundle that run the ‘scripts’ from Symfony Standard Edition and can be placed in the root application’s ‘composer.json’. This way, the application wouldn’t have to change those scripts unless Symfony Standard added ‘scripts’ for more events (since they are specified with the composer event they are to be run for).

Continue reading post "Working with Composer ‘scripts’ and ‘extra’ from Non-Root Package"