Hacktoberfest 2019 x Extreme, Part III — Mike's Contribution to Composer
How did Mike, our Head of Dev, give back to the OSS community for Hacktoberfest? Part three is here — read all about MvR's work on a useful, time-saving Pull Request!
I started in PHP development back in 2003. To say the language has progressed in the last 16 years would be an understatement.
Back then, pretty much everything was written from scratch and mostly based on procedural code. Now, developers rely heavily on pre-built functionality, frameworks and libraries.
That’s not to say we don’t write any new code, but often these dependencies take care of the really dull side of development which then allows developers to focus on the fun stuff.
If we look at a fresh installation of CraftCMS built through Extreme’s own bootstrapping tool, without doing anything already the software requires 14 PHP packages to function. This includes CraftCMS itself, plugins to use forms, for 301 redirects and some Amazon services amongst other things.
Once development begins it easy to see how these dependencies could become unmanageable if left to the developer. Luckily, we don’t have to worry too much about keeping on top of versions, updates or installation of packages because we have Composer.
Composer is PHP-based software which is the industry standard tool for managing PHP dependencies.
Through the CLI (Command Line Interface), developers can easily install packages from remote repositories and make them available to their applications in one command.
Composer also keeps versions in check by controlling when updates are made and keeping the code base the same for other developers, which is really important when working in teams.
Quite fittingly for Hacktoberfest, if developers want to create their own PHP packages as OSS, they’ll need to develop and test their codebase locally before having to push to a remote repository. Composer provides a mechanism to do this through the composer.json file.
Running composer install should then copy my-package from the local path in to the project.
The problem we were trying to debug was why Composer kept installing the package from the main project repository and not his local version. Eventually we realised it was because the url path provided didn’t exist (🤦) but, for some reason, it failed silently which we thought was wrong.
So today I spent a little while putting together a Pull Request that checks if the url path exists when composer install is executed with a local repository.
If it doesn’t, then an Exception is thrown that then shows an error message on screen, that should be more obvious to debug the problem. It certainly would have saved Joe and I an hour between us.
Working on such a well-used project was a good experience, with well-defined code standards and Unit Test requirements. Fingers crossed my PR gets approved!