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.
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"
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"