Most PHP projects eventually pull in open source libraries from Composer. All of these Composer dependencies must be updated regularly to avoid security holes or incompatibility issues with new software. I do a couple of things before updating a dependency to make sure the update doesn’t break anything.
Figuring out what might break
Some Composer packages provide a
CHANGELOG.md file, which is a great way to know if updating will break a website. But reading through dozens of changelogs can take a long time. Because most Composer packages (or at least well known ones) rely on SemVer to publicize what might have changed between two releases, there is usually no need to read through changelogs.
SemVer says that any software packages should have a version of the form
<major>.<minor>.<patch>, for instance
major part changes, there is a breaking change in the package. In that case, I verify if any code is affected and needs to be updated. Whenever the
minor part changes, there shouldn’t any breaking change but in practice, I’ve seen breaking changes for
minor updates, I prefer to read the changelog. I have very rarely seen breaking changes with
patch updates, although they can happen if the code relies on the bugged behavior.
Viewing composer version changes after an update
To get an overview of version changes after a
composer update, I use
git diff and
git diff composer.lock | grep -B1 -E ' "version"'
The output looks like this:
From there, I take a closer look at the changelogs from packages for which a
minor version has changed.