Introduction Composer 2
It has been six months since Composer 2 saw the light and I finally dared to deliver some Drupal projects entirely with Composer 2. Anyone who works with composer knows that after years of using `composer require`, you have learnt by now a second language, you can play a new musical instrument, or dive into the downward facing dog with convincing flexibility, as if you were an accomplished yogi. Time and again the upheaval was great when, after getting two cappuccinos, you found out that 'composer require' had done nothing at all, because there was a “Your requirements could not be resolved to an installable set of packages.” - message on your screen making fun of you.
But that, dear folks, is all a thing of the past with the arrival of Composer 2. You blink your eyes and all of a sudden the packages have been downloaded, or you immediately get a message that it was not successful (still) by those “installable set of packages”.
Does it end well?
Not quite yet. In this phase you may need version 1 for one project, and version 2 for another project, or an even a more specific version.
There are several ways to deal with this:
- Switching between the projects and each time performing a `composer self-update –2` (or 1)
- Create aliases and decide per project whether to call composer1 or composer2.
But I came to the painful discovery that in an unguarded moment I accidentally used version 2 where version 1 was needed, and suddenly encountered strange problems, which, moreover, I could not be tied to, and which probably something had to do with the big mysterious composer cache! (One should investigate what you can encounter there nowadays… but unfortunately that goes beyond the scope of this blog).
Automate
Anyway, to prevent this disaster I suddenly had to think of a few lines of very smart, simple code that had been devised by an old colleague in the distant past, when we all had this same problem with drush and it made you pull out all of your hair because you had to think over and over again what version you needed for your current project. And we all know thinking is for the faint of heart, and didn’t we just become a programmer to not have to think too much and above all just to automate things, to make life better?
In short, it boils down to the following:
- Create as many composer versions as you want (download from https://getcomposer.org/download/)
- Per specific version you can do for example
mv composer.phar /usr/local/bin/composer1
Now create a bash script containing the following code:
#!/bin/bash
version=$(git config --get composer.version)
if [ "$version" = '1' ]
then
echo composer1
composer1 "[email protected]"
elif [ "$version" = '11015' ]
then
echo composer11015
composer11015 "[email protected]"
else
echo composer2
composer2 "[email protected]"
fi- Of course, this is an example for inspiration.
- Place this bash script wherever you want but make sure the script is executable, for example:
ln -s ~ /Scripts/composer.sh /usr/local/bin/composer
- Now go to the root of your website folder (which also contains the .git folder).
cd /var/www /…
- Put your desired composer version in .git/config
git config composer.version 11015
- Test if this works:
composer --version
- This should show the version you just entered (1.10.15).
Tadaa! From now on, life will get much better. And another nice side effect is that you can finally tackle that coffee addiction ;)
