This morning a tweet caught my attention prompting me to read this post by Gary Hockin also known as @GeeH. (There’s just something about that voice.[inside joke]) In the post he talks of his experiences while attempting to simplify code in a project, and in the process uncovers hidden dependencies that increased the codebase significantly in order to gain the benefit of a mere 100 lines of code. He also highlights that in today’s mainstream PHP development, where many are using Composer to blindly include packages into applications, we may not fully understand code being pulled in with the consequence of accepting responsibility to maintain those additional packages as well.
I’ll wait a second while that sinks in…
Yes, that’s right. If you include additional packages and libraries into your application you’re accepting the responsibility to maintain them. No, I’m not saying you are responsible for contributing to the software package…unless you care to. What I’m saying is you are now in charge of updating the software within your application, which now includes additional packages created by others. As security holes get fixed, or new versions come out fixing bugs, it is up to you to ensure you update these packages in your applications which include them.
You’ve been living in a dream world Neo
Ha, didn’t think about that, did you? If you did, Bravo, you’re behaving like a professional. For the rest, welcome to reality. Now go update the applications you’ve neglected. But first a side note.
I’m not saying Composer is bad. Actually I think the opposite. Composer is awesome, and you should be using it if you’re not already. As in the post by Gary above I’m simply saying it’s our professional duty to know what we’re asking Composer to do on our behalf. Use it responsibly and do a bit of research so you’re not blindly including potential issues, bugs, security holes, and nightmares to maintain in the future. Then if you’re satisfied with what you see, go ahead and “require” away.
But wait! Don’t just look at the packages you’re including into your codebase. Also take a look at their dependencies as well, because you are also accepting them in the process. Know what you’re saying “yes” to.
None of what I’m saying is new stuff. A while back, in the beginning of 2012 (I thought it was earlier for some reason), Ed Finkler @funkatron wrote the original MicroPHP Manifesto to voice his concern over many frameworks starting to grow in size. (NOTE: Later there was a separate domain dedicated to housing the MicroPHP Manifesto, but I like the original better because the blog post associated with it helps highlight why it’s a concern.) I encourage you to check it out and consider the meaning, and how it relates to your projects.
Again, nobody is saying large full frameworks are evil or other libraries should not be used. The idea behind all of this is to caution, so you go in with your eyes open and “know” what you’re including in the codebase. Know the responsibilities accepted by including other libraries.