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 getcomposer.org 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
composer posts
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.
Deploying updates to my site with a composer lock file seemed slower since updating to version 2, so maybe it isn’t faster in some circumstances.
I see that composer has released its 2.0 version. Nice.
Apparently at some unknown point in the past, Github changed something about their webhook / service connections, and Packagist added a requirement, when using Github to log in, to take control of the account’s webhooks.
Continue reading post "#2338"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.
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"