Some people love Composer.
They use it to build their PHP projects and manage all the external libraries and dependencies. They love it so much they say things like this: “Composer should be the only way to build a Drupal code base.”
That approach is misguided, and I’m going to give you 5 reasons why.
Composer is a great tool, but it’s far more limited than some people realize.
I’m going to mostly write about Drupal in this blog post, because it is further down the Composer path than any other CMS. But, some platforms like Magento and Typo3 are headed that way too.
#1. Usability problems
In Drupal 8, the Address module must be installed via Composer. So, if you want an address field on your Drupal site, you have to be able to use Composer.
In Magento 2, the theme installation process is unreliable, and the only sure way to install themes is with Composer.
That has prompted concerns about leaving ordinary non-experts behind. There is an issue on Drupal.org asking not to require Composer unless a user-friendly interface is also included.
There have been some steps towards a user interface for Composer. And, in Drupal it may be possible for future versions to include Composer management in the Update Manager. However, there’s a long way to go before this is a solved problem.
#2. International problems
Composer is often inaccessible in some countries. Composer relies on Github, which is regularly blocked by the Great Firewall of China. You can find several complaints about this, plus more from people behind regular corporate firewalls. I mentioned this on Twitter, and George Wilson from the Joomla team replied that they develop under the assumption that Composer will fail for a sizeable number of users.
#3. Composer can be a resource hog
Composer’s dependency resolver eats resources and means it can be unusable on shared hosting. Composer again makes it difficult for low-end users.
#4. Best practices are still in flux
Yes, there are official best practices for using Composer in Drupal, but no – they are still a work in progress. This is a sobering story with several core Drupal developers trying to follow the recommendations.
Jeff Geerling has a wonderful post that summarizes the all issues in detail. He concludes:
There are still some growing pains as the Drupal community more comprehensively adopts Composer and structured dependency management in general.
One Drupal user commented:
We were told about the Composer changes and not to worry, only core developers will need to use Composer. Fast forward, and now there is a push to force all Drupal installs to require Composer to just install. I have been trying to follow all the best practice advice and use Composer to manage my projects, and it has been a huge pain in the ass!
On the WordPress side, Iain Poulson talks through a variety of proposals and problems. Read that to see how far WordPress has to go before any kind of reliable standard is agreed upon.
#5. Do you really need it in production?
Pascal Morin from Code Enigma makes the case that Composer shouldn’t be used in a production environment:
<blockquote><p>If you use Composer to build your code in production, you get:</p><ul> <li>Un-needed and time consuming deployment complexity increase, with small but real risks of failure on each and every build for external cause</li> <li>No auditing of changes that are not your own custom code</li> </ul></blockquote>
A number of promiment Drupal developers strongly supported this view, including Earl Miles, the developer of Views.
Wait, Steve. Do you hate Composer?
No, no, no, no.
We just spent weeks of effort and several thousand dollars to publish a massive new class on Composer. But it’s not right for everyone, or for every platform. Michael Babker from Joomla describes it this way:
Composer wasn’t designed for use in a CMS environment like WordPress or Joomla where end users are managing it 100% through a web UI.
Composer is a great tool, but I’m very sceptical that it should be required by any CMS system.