(or how I stopped blindly including shit in my composer.json)
I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I’ve had a terrible day and I’m hoping that the process of just getting this off my chest will be therapeutic in some way.
It started with a hydrator…
So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker. “No problem”, I thought. I’ve used Zend Framework 2 a lot (and as an aside, I’m now a ZFCA – woo hoo!), Zend\StdLib includes a set of hydrators that are specifically designed to cleanly solve this problem.
A quick look on packagist tells me that this component has no dependencies on any other component inside or outside of ZF2. That’s a win for reusable code, so I added it to my composer.json.
Running my tests gave an unexpected error: It appears that Zend\StdLib\Hydrator\ClassMethods (at least) has an undeclared dependency on Zend\Filter. A quick conversation in IRC later and I find it also has an undeclared dependency on Zend\ServiceManager.
At this point I feel I should apologise to Marco – having a very bad morning is no excuse for being a fuckwit in IRC and rage-quitting when your opinions are questioned.
I also want to make it clear that my beef here isn’t with the undeclared dependencies in this component, that can be easily fixed and then the choice on whether to use it or not can be an informed one. My concern is over the number of people who would willingly and happily add the extra dependencies to their project in order to use this component. Zend\ServiceManager is currently 2,511 lines of code, and Zend\Filter is 7,351 lines of code. As far as I can tell (and don’t quote me here please, its a token guess based on 10 seconds of looking at code), the hydrator only needs the Word filters which are around 100 lines of code. So, using my amazing rounding techniques to make something look simpler that it is, by my maths, Zend\StdLib\Hydrator\ClassMethods imports 10,000 lines of code to make use of 100 lines. That’s 1% of the lines of code imported that are actually needed.
So, this is where the contention happens. I can almost feel the overwhelming weight of apathy barrelling towards me as the literally tens of people reading this blog shrug in indifference. And that’s fine.
“Disk space isn’t a problem any more”
“You are a stupid idiot”
These are just some of the responses that I’ve got when moaning about this on IRC and on Twitter, and that’s perfectly fine. If you’re happy to let Composer pull in many and unknown dependencies so that you can use one or two classes out of the hundreds it installs, that’s completely fine. It’s your project after all. But I’m actually starting to sway away from this unchecked use of Composer.
Simplify All The Things
Around a year ago I first came across Ed Finkler‘s MicroPHP Manifesto. Of course, being a big advocate of the Zend Framework I immediately discounted it. But over the intervening months I’ve started to move further and further away from the full stack framework in some cases.
Of course, for some cases full stack is still my prefered framework of choice. Our client and admin back-end still leverages the power of ZF2; for one it makes user entry with Zend\Form (among other components) much, much easier. But when we rebuilt version 1.5 of our SDK, and now, with the forthcoming version 2 I want some of our sites to be as lean and lightweight as possible. This is where I am starting to really buy into the less-is-more ideals laid out so succinctly in the MicroPHP Manifesto.
I don’t want to have to maintain several packages for the sake of a small amount of code that I actually use in my project. I don’t want to have to worry about what versions of packages I’m running on my server or what versions of components are being pulled in as dependencies of my dependencies. And I don’t feel that this is a trivial as some others do. I don’t have the time to keep up with the changelog of all the components I have blindly installed to check if there are security fixes and I should update.
Composer Isn’t The Problem
Some people on Twitter saw my rant and wrongly interpreted it as a rant against Composer. It’s not. Composer is an awesome tool that in my mind has been responsible for a renaissance in PHP in the last 18 months. Composer has been the tool that has allowed me to blindly pull in multiple dependencies, but it’s not Composers fault. It’s my fault and the fault of the all the developers who have encouraged a community of thoughtlessly including code in projects.
So there it is.
The rambling rant of an annoyed man. In future, I’ll be thinking long and hard before including any dependencies in my composer.json, and I think you should to.