In the last few months I’ve been using Composer to improve my development and deployment of WordPress projects. It’s an important tool that is not only easy to use, but also leads to increased code reusability, a reduction in copypasta errors, encourages best practices like using namespacing and autoloaders, and can aid in deployments.
I’ve covered how composer works in my posts for Torque on the subject already. But, in this post I wanted to just briefly go over the various scenarios in which composer is useful and how it can improve your life, and increase your personal powers as a developer and a human being.
If you are new to Composer, I recommend that you read my Torque posts on it. So far I have written an introduction to using Composer with WordPress and a guide to improving WordPress plugin development with Composer.
Improved Site Deployments
One of the trickiest things about moving between a development and production site is dealing with the parts of the project that do not belong in version control. Sometimes you end up with all of your plugins, and WordPress itself in the Git repo you use for the site.
This is, objectively speaking, an absolutely terrible idea. Why should you write every change to WordPress or a plugin to your Git history? That makes no sense. Use version control to track changes to code you are changing and no other code.
For HoloTree, we have a Git repo for building the live and development sites that establishes the structure of the site. It includes wp-config, my VVV config and a few other things, but does not include any plugins, the theme or WordPress itself. All of that gets pulled in by Composer.
Mark at Kinsta helped me set up dploy.io to automate the process. Since dploy.io connects to my server via SSH, it is able to run composer update for both the main repo and the plugins that power HoloTree, each of which pull various libraries.
This is all made easy by the fact that every plugin in the WordPress.org plugin and theme repositories are automatically available as a Composer package, thanks to wpackagist.
Update: I created a git repo that has everything set up for new WordPress site development using Vagrant, and my preferred way of using Composer for dependency management.
Sharing Code Between Plugins
As you go through life, you will find yourself developing repetitive patterns you like to use in all of your plugins. That’s great, unless you are cutting and pasting those patterns between projects.
Moving the classes and collections of functions you use for a part of a project into a Composer library is a little bit of extra work. You will see a return on investment for that small amount of work the first time you use the library again. When you fix a bug in the library and are able to easily share the change across all projects using that library… well that’s just awesome.
Using Other People’s Libraries
Packagist, GitHub and the internet at large are full of great libraries that you can pull into your plugin or other project using a dependency manager like Composer or NPM. Using a dependency manger makes doing so both easy to do and easy to keep up to date.
If you ever wanted to use a piece of another PHP framework, say for example Symphony, Composer makes it easy. Also, some talented WordPress developers publish libraries on Packagist. For example, Mark Jaquith, Andrey “Rarst” Savchenko and Eric Mann.
Of course, a package doesn’t have to be on Packagist. If it has a valid composer.json file, you can pull it directly from GitHub.
Composer Libraries Are Git Repos!
Note: I know they could be SVN or whatever repos, but using anything besides Git is, objectively speaking, silly.
Let’s say you have a plugin constructed of several Composer libraries, and one file with the plugin header and a function to include the autoloader. First off, great victory, you win a _doing_it_right() award in my book. You might be worried about having to maintain separate checked out version of the repo to commit changes to.
This is not the case. When Composer pulls in a package, it includes the .git file and sets the remote origin properly. If you have write access to the repo, you can simply CD into the package’s directory and commit and push like any other Git repo.
No New Copypasta!
Don’t Repeat Yourself (DRY) is one of the most sacred principles of programming for good reason. Cutting and pasting the same code between files is an equal, if not greater violation of this important principle.
Not making your code easily reusable for the benefit of yourself and others makes your life harder. Further, it robs you of the ability to help others while promoting yourself.