Want more? Sign up for my weekly newsletter
Using it Drupal.org GitLab CI
Now we’re here. A wild idea that has become an integral part of Drupal’s major version upgrade process.composer (next major):
variables:
_LENIENT_ALLOW_LIST: token,pathauto
That’s pretty cool.
What is this “lenient” stuff?
So, I had no idea that my plugin was integrated into the GitLab CI templates. Here is an example from the documentationWell, it’s official. My Drupal Lenient Composer Plugin has allowed the lenient Composer repository endpoint on Drupal.org to be sunset and removed. I created the mglaman/composer-drupal-lenient repository two years ago at DrupalCon Portland. It is pretty wild how much it has been adopted in just two years. Not only has it allowed the Drupal Association to dismantle some infrastructure, but it is also baked into the Drupal.org GitLab CI. The package is pushing over 3,000,000 downloads from Packagist!I can’t remember why, but I know I was talking with Jakob Perry, and the next thing I knew, there was a wild idea to encapsulate the concept as a Composer plugin. The problem with the Composer repository endpoint is that it worked for everything rather than specific packages. My Composer plugin allows you to opt into individual packages.Contributed modules and themes must be updated whenever a new major version of Drupal Core is released. Their info.yml and its core_version_requirement constraints to specify they work with the latest version of Drupal Core, even if no actual code changes are required to work. The same happens with PHP packages when a new version of PHP is released. They need new releases updating composer.json with the latest minor or major version of PHP allowed.
drupal/core. This allowed Composer to bypass conflicting constraints on the support version of Drupal Core for any module or theme. It was a way to allow Drupal users to apply patches to modules and upgrade Drupal Core even before their dependencies were fully ready.
