In my new position at GrokSpark, I’ve been building out the company’s 3MS MVP from scratch in PHP. I’m sure I’ll write a post on why I chose PHP (I can hear the self-righteous and poorly formed opinions about why PHP is awful already), but for now I wanted to focus on something a bit more specific: Using Composer with GitHub repositories as way to temporarily circumvent a shortcoming of using open source libraries.
Stale Repositories
One of the libraries I’ve employed in my system for GrokSpark is Pseudo, a fantastic mock PDO library that I can use to test things such as my data models. Though the library is fantastic, it also presented me with an issue that’s a bit more common in open source work than some people care to admit.
The system had some minor issues, which others had contributed Pull Requests in order to fix, but their work wasn’t accepted before other updates were made to the core. This made the PR’s stale and the contributors hadn’t yet responded to the requests to update their code so it can be accepted.
This is completely normal and part of the open source process, but waiting didn’t mesh well with the urgency I have for our MVP. Sadly, since there aren’t many options for PDO mocks, I had to take matters into my own hands…at least temporarily.
Composer and GitHub
Thankfully, Composer already has the concept of Repositories built-in. There’s a lot of information available there, so let’s distill it to just the basics we need in order to access my new GitHub repo (I’ll assume you can fork a repository on your own and make whatever changes are necessary).
First, we open our composer.json file and add the GitHub repo to the ‘repositories’ array:
"repositories": [
{
"url": "https://github.com/AndyM84/pseudo.git",
"type": "git"
}
],Next, add the package requirement (I put mine in require-dev since I don’t need this in production):
"require-dev": {
"phpunit/phpunit": "^7",
"jimbojsb/pseudo": "dev"
}Even though this is a personal fork of jimbojsb/pseudo, the package name must remain the same as is present in the library’s composer.json (which is jimbojsb/pseudo in this case). You’ll notice I set the version to simply be “dev”, which is done on purpose. Now, run the following command and let’s see what it tells us:
D:\P\G\R\3ms [master]> composer update --no-suggest
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- The requested package jimbojsb/pseudo dev exists as jimbojsb/pseudo[0.3.1, dev-master, v0.2, v0.2.1, v0.2.2, v0.2.3, v0.3, dev-AndyM84/22] but these are rejected by your constraint.Now we see why I’ve set the package version to simply be “dev”. This produces a list of available dev versions to specify. In this case, we’re going to use the one that is the branch I created to include my changes, “dev-AndyM84/22”.
When I change the version for “jimbojsb/pseudo” to be this version and re-run composer update, it will pull the AndyM84/22 branch from my forked repository.
Conclusion
There isn’t a lot to this process, but it can be a life-saver when your timeline is a bit faster than the pace of an open source library you truly need in your code-base. And best of all, when the main project finally contains the changes you’re looking for, you can simply switch the version and remove the repository before re-running composer update and Composer will take care of switching the versions for you.
Hopefully this saves somebody a few minutes of time and a lot of frustration while you live within the open source world.
Finally, it should be noted that the parties involved in the PR for Pseudo actually came back to life fairly quickly after I prodded them, so a super huge thanks to them for ensuring this really was a temporary fix in this case!
– Andy