5 Reasons Not to Require Composer in Your CMS
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.
At the end of the day, it’s all about the right tool for the right job. I love Composer and how easy it makes managing dependencies, and appreciate all the effort that has gone into making it work, but I’ve shifted away from a workflow where I run git and Composer on live servers in favor of a deployment workflow where everything is provisioned by CI (so if a deployment is going to fail because Composer can’t resolve dependencies, it’s going to happen in a provisioning space, not a live server and bring the site down). As long as your primary distribution model is targeting a lesser technical end user where SSH, FTP, and other TLA’s scare them, Composer isn’t a tool you want to force on them. But if your model is more developer focused, where you aren’t expecting that lesser technical crowd to maintain the application through a web UI, going more toward a Composer workflow isn’t all that terrible. For established projects, making that shift in approach probably won’t be received well by a fair number of users, but for newer platforms I’d really encourage project leads to evaluate what their goals are and pick an approach that suits them.
(Somewhat on topic, we started doing ecommerce builds with Sylius instead of something like a WooCommerce or Magento solution, it’s been really interesting explaining to the client some of the philosophical and management differences in a web managed app versus one that has more of the developer oriented approach)
What a killer comment, thanks Michael. You summed things up better than I did in the article. Yes, perhaps if a project like Magento only wants expensive, enterprise-level deployments then Composer is a good fit (that’s not crazy – Magento’s leads have said something similar before).
aye what he said ^
Well said~ I’m one of the non-experts. I heavily depend on GUI even installing a single module. Pushing us to use command line via Drush and now Composer is really overkill. Drupal will eventually turn many away and seek other CMS which make life easier. It looks like Drupal is getting more and more complex that needing all these development tools to maintain and develop. I used to claim anyone can build their site with Drupal, soon it will no longer, but only left to those who are experts ~
At my skill level I can only claim to be a Site Builder. I’m learning WordPress, sad to say.
Thanks for the feedback, Simon and MeFree.
Is Composer specifically an obstacle for you? Or is it just indicative of a much more developer-focused mindsent?
Steve, I have not taken the Composer course yet, but I know, for certain, that I am not a Developer. I learned Unix command line at least 20 years ago, so I understand the advantage of using Drush, etc. However, I have no one else on my team to bounce off issues with. My Calendar module still has a bug in it because I’m too nervous to install the patch on my live system; I was able to do so on a dev system. I’m applying the Dirty Harry Principle “A man’s gotta know his limitations”. 😉
I love the Linux cli. I don’t love composer … yet. Not saying it won’t happen, but it seems to not be very intuitive, and a beast compared to drush, but I never HAD to use drush, but when I did figure drush out I loved it because it made life just a little more simple. I don’t like that some module builders are making composer a requirement.
Thanks Scott. Yes, that’s exactly my feeling here too. I love that Composer is an option, but I’m really nervous when it becomes a *requirement*.
Same here … We’re trying to use Laravel for a project but the Composer “requirement” is a real PITA. I’d much rather simply download whatever code we need — as we’ve done since 1997 — and use it “as is” until we need to update it. We’re having enough issues with GitHub, and now the Composer “cottage industry” people have inserted themselves into the mix. That’s probably the fault of Laravel, but we’d prefer a much more reasonably-understandable approach to this mixture of ‘version control’ and ‘3rd party package’ use. This has gotten ridiculously obtuse compared to simply making a change and uploading it.
We recently rebuilt our CRM software in Joomla. We were advised to use composer and did so. I’ll be honest I didn’t get on with it at all. I understood the concept, and the idea was great in principal. But it was an absolute pain to work with in the long run.
Ended up ditching it totally in the end!
I’m finding composer to be very problematic as well as a lot of arrogant stuck up people around it being little fuhrers going around ordering people to do this or that like that they must keep their lock file in VCS.
Composer has a myriad awful problems asides from attitudes, it has technical problems. I basically feel the same overall. I’ll point out the great firewall of chine problem has quite a large scope and isn’t entirely on composer though when it pulls stuff from git that is a questionable model as opposed to its own repository system.
The problem with building in composer failing isn’t necessarily on composer but composer’s attitude about how you should do things and that of the user’s stinks. That’s related to best practices. I don’t like the term but it generally is a best practice to not have builds depend on external resources. The simple fix? Include vendor in your VCS. It’s best really when fetching external resources is a separate part of your build pipeline.
This is perhaps something composer should make easy. For my systems I always have a separate dedicated layers to managing external dependencies. That might consist of things like aptly, rpm mirror, pip mirror, docker image mirror, scripts for downloading things from websites, etc. All that contains is for each thing scripts for getting the resources, configuration of what to get, the storage for each thing and then a means of accessing it which is what development, testing and build machines use. Currently for composer satis is used to achieve that. I’ve not used it heavily and I’m on the fence about whether it’s any good at this point. These aren’t really systems for the average case and there’s a lot of mixed levels of maturity as well as complexity. You would not believe how stuck up and arrogant people can be about this stuff yet how wrong they can be. As in apparently the best practice is to log into every production machine, git pull and then run composer update one by one.
There is of course another simpler point to this. You never build your code in production, that’s just rule number one, or at least if you do in the sense of doing it on the production server then it builds in another folder and then on success copies over. If you’re using a managed system of sorts or software that’s meant to manage that for you then it’s what that software should be doing. I once just got fed up and quite a job on the spot during a meeting once because I just had enough of people insisting on building in production and then screaming at me interrogating me in meeting after meeting for spending 30 minutes to fix all of that.
Like you, I’ve independently found these problems and have pretty much the same thing to say but with a bit more detail and I think what’s really clear to point out is that you specifically say this is bad for people already in a bad situation but it’s so bad it’s just bad not matter the user’s circumstances.
[b]It’s totally unintuitive and not clear what it’s doing.[/b]
Sometimes it uses composer.json, sometimes composer.lock. Sometimes it only updates one, sometimes both. Sometimes it installs to vendor, sometimes not. A simple case of this, you add something to composer.json and then do composer install. Nothing happens because it’s using only composer.lock.
To actually do something once there’s a composer.lock it always wants to update, everything. Composer require and composer remove by default also do composer update which does more than you might intend. This is especially problematic as sometimes the only way to get composer to actually do something once there’s a lock is with update and update does a bunch of things unrelated to the one thing you want to do. This invokes another serious bug.
When it finds conflicts it lists them saying problem but then under the problem rather than explaining what actually conflicted it gives a ridiculous massive list of what it thinks you should do. Often none of those solutions are appropriate. I do not understand how hard it is to just say a -> b -> c1.1.2 and x-> y-> c1.2.2 don’t match.
I’m an expert and I can assure you the problem isn’t that composer isn’t leaving the non-expert behind. It’s that it’s just play awful. That’s something it inflicts upon everyone.
[b]Its performance is a disgrace[/b]
Composer has serious problems fetching external resources and likes to get things from lots of places one after the other very slowly. A lot of operations are dog slow in composer. Running install takes an age.
When updating (resolving dependencies), it uses gigabytes of memory and that really makes no sense. It’s gotten slightly better in new versions but it’s still dog slow and really quite amazing just how much resources it needs. Out of a dozen package managers for different languages and operating systems there’s nothing at all approaching composer in terms of resource consumption. When it takes a couple minutes and over 4GB of RAM to upgrade a single package that’s just not acceptable.
This isn’t even about shared hosting, etc. It performs terribly on machines with stupendous specs.
[b]It’s the main PHP package manager[/b]
There’s basically no good alternative. It’s the same thing as for example if you use centos, you can’t really fully abandon using yum though saying that there are some alternatives in that case.
The notion that composer forces people to use the command line I don’t really think is a good criticism against composer but might be a good criticism for where things switch from one thing to another that for example might have GUIs built on top of it and composer hasn’t.
Thought on the one hand I’d also say users are a bit more afraid of the command line then they should be because it can be surprisingly easy and should be. On the other hand given how badly composer has failed and how terrible it is when it comes to command line use I wouldn’t blame anyone trying to use composer on the command line of them being afraid of composer. What’s important here is the problem isn’t the command line. It’s composer. You have this hell even if you have your composer tool wrapped a level 99 GUI of usability.
Composer isn’t terrible because of what it is. A command line package manager for PHP. It’s terrible because of how its construction. It’s as simple as that. Whoever thinks a system that takes several minutes and huge amounts of RAM to resolve dependencies in cases that should not be difficult needs their brain examined. Most of the time composer is doing this as well it’s when I want it to do things that are nothing to do with the stuff it’s looking for. I want to simply install or uninstal package A which has no dependencies nor anything dependent on it yet I must fight tooth and claw to try to stop composer from trying to solve everything and anything. That doesn’t mean it’s not wrong for a software solution to basically remove their GUI for installing additional features or addons which is what we appear to be talking about here.
What’s wrong with hating that “composer”? It is _bad_ tool. Yet another dependency your project has. Yet another magic _proprietary_ processor. Under proprietarity I mean you have no control over their infrastructure and decisions. They can require you doing any new configuration and hussle so you will have no choices. Old good copy-paste (files/archives) is our best friend. Not CLI utilities and remote repos.
I don’t understand why more isn’t made of the very last point: “No auditing of changes that are not your own custom code” – if you have a stable release, wouldn’t you want to lock down your code base? I might be misunderstanding something, but in theory, you could publish a stable release then do no dev work for three months, fire up the beast and suddenly a bunch of libraries on which you depend get updated by publishers and your app may well even break. Can someone enlighten me on how this is prevented?