I’m a big fan of Composer, which I believe will give you super powers. I am happy that it is gaining in popularity in the WordPress world. I often hear from developers who love it, but are not sure what to do about the vendor directory in their plugins or themes or sites.
I spoke about the advantages of challenges of using Composer in a recent episode of The Plugin Architect podcast. I use Composer in most of my plugins. Most of Ingot’s code is in Composer packages, which helps us share code between different versions and add-ons. I also helped refactor the plugins Maps Builder and Maps Builder Pro by WordImpress to make sharing code between the pro and free versions easier.
Often times people are not sure what to commit or gitignore and the best way to deploy their code to keep their package size small. I’d like to answer a few questions to help you make the best of Composer for WordPress development.
Should You Ignore The Vendor Directory In Your Git Repo?
A lot of people are hesitant to gitignore the vendor directory and other dependencies in their GIT repos. Most of the managed hosts encourage you to use GIT to manage your dependencies when using GIT as a deploy tool. This is not good practice for a few reasons.
First, it is messy and redundant. Why should I use a GIT to manage changes in code that is managed by a different VCS system? It doesn’t make sense. A change to a dependency should require a commit in the configuration file for Composer, Bower, NPM, etc, but not commits of actual code.
Also, keep in mind that by default, Composer checks out all packages as GIT repos. That’s great in development, but not something you want included in your final product. Composer is built with this in mind. But you should not ship your plugins with Composer packages as GIT repos or push GIT repos of dependencies to your site.
Down with redundancy and bloat, folks.
Let’s talk about two scenarios, site deployment and shipping plugins. The solutions are pretty similar.
The first situation is where you are deploying a site using GIT and Composer. If your live server has Composer installed — a rarity for some bizarre reason in the WordPress managed hosting space — then this is easy. Use Composer to manage dependencies and gitignore the vendor directory and when you deploy use the –prefer-dist argument to tell composer to not checkout the whole GIT repo.
Laravel Forge, which is a server provisioning and deployment system of industry, has this line in its default deploy script:
composer install --no-interaction --no-dev --prefer-dist
This tells Composer to install with none of the packages that are required for development only, like your unit test framework, and to get the packaged distribution of the dependency, not the whole GIT repo. I have no idea what
--no-interaction does, but let’s assume its good.
You probably want to add –optimize-autoloader to that if you’re not using Laravel, which runs that in one of its post install scripts.
I make more plugins than I make sites. Most Caldera Forms add-ons use Composer to manage at least two dependencies. I’ve written a Grunt script that helps automate this process. It checks out all of the dependencies using
composer update --prefer-dist and then copies everything to a sub directory, which it then zips and deletes.
This means that my plugin repos, have a directory, usually called releases, with a ZIP file I can upload to our site. I used to add an automated SVN deploy when I was working on plugins that need to go to WordPress.org. Now I just open that ZIP file and drag it into a new tag inside the SVN repo, opened with phpStorm and commit that.
There are a few other challenges when using Composer. But I really do think they are outweighed by the benefits. Composer is an essential part of the workflow for modern WordPress development.
Composer is a great tool, and I hope you will try it, and when you do, this will have helped you learn how to make it work properly with GIT.