PHP has one of the greatest, in my opinion, dependency managers – Composer. The tool works mostly with the public projects via the Packagist website (although it also supports private repositories).
There are over 200,000 packages available on the Packagist to choose from. However, the stats could be a lot better.
Today I came across a mind-blowing visualization of the composer packages and the dependencies between them. Have a look at Code Galaxies Visualization. You can find specific packages via the search, or interactively navigate the star map, like you are in the spaceship.
Dependency managers have scaled this open-source code reuse model down: now, developers can share code at the granularity of individual functions of tens of lines. This is a major technical accomplishment. There are myriad available packages, and writing code can involve such a large number of them, but the commercial, legal, and reputational support mechanisms for trusting the code have not carried over. We are trusting more code with less justification for doing so.
Not only it nicely describes the problem in simple terms, but also provides practical examples and solutions to it. In particular, I enjoyed the section that suggests how to improve dependency evaluation in terms of design, code quality, testing, debugging, maintenance, usage, security, and licensing.
#ProTip In your #PHP application add "composer show -mlDo –strict" to your build pipeline to let your build fail when there are outdated dependencies. You could for example only run it in feature branches to make sure your team keeps the dependencies up-to-date.
We’ve been using Semantic Versioning for quite a while at work now. It’s easy to explain and follow, and it provides valuable context to the numerous releases of the projects and components that we are doing on a daily basis.
Turns out, however, that I missed a small, but important part of the standard. All releases in major version 0 are considered to be unstable, so even if they introduce backward compatibility breaking changes, there is no need to increment the major version to 1. Here’s the relevant quote:
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
If you are relying on the semantic versioning in your projects, make sure to check your dependency management tool, to verify that it handles major version 0 correctly. Gladly, for us, composer does the job:
The ^ operator behaves very similarly but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.