If you’re a WordPress developer who is using Composer without continuous integration, then odds are you’re left with a crucial step of figuring out how to manage the vendor directory when deploying your plugins.

Composer Without Continuous Integration: Composer

That is:

  • We know it’s a bad idea to throw the entire vendor directory under source control,
  • Other developers who are familiar with using Composer should be able to get up and running without the need for much instruction,
  • Continuous integration isn’t being used for any number of reasons,
  • And we’re left with needing to provide a production-grade deliverable that uses certain dependencies but not others.

As much as the above points may describe our situation, it doesn’t tell us what we can do with it.

In other words, here’s the use case: You’ve built a WordPress plugin for someone. This plugin uses a variety of dependencies all of which are maintained by Composer.

You’re not checking the vendor directory into the repository, but you’re also not using continuous integration to deploy the plugin. Instead, the customer is, or a third-party is.

So what then?

Distribution with Composer Without Continuous Integration

The short version is this:

Export the master branch (or release branch or whatever you call it) from your local copy of the plugin, then make sure you run the Composer command that instructs it to create the vendor directory without the development-level dependencies.

Then you can bundle up the generated archive and distribute it to your customer.

But How?

First, I’m assuming that the local copy of your plugin does not have a copy of the vendor directory but has all of the latest code pulled from the remote repository.

That is, you have the latest, stable version of code ready to be released but you’re not yet ready to do so because it doesn’t have the necessary dependencies for, say, autoloading and other similar functionality.

The first step is going to be exporting the local repository into an archive. Here’s how you can do so by dropping it on to your desktop:

View the code on Gist.

Next, instruct Composer to install the dependencies that are outside of the require-dev directive in your composer.json file:

View the code on Gist.

Now you can archive the generated directory into a plugin and distribute that file.

Is This Ideal?

I wouldn’t say this is ideal but it’s a solution to a use case that certainly exists, so I’d say that it’s something that can be done to solve a specific problem.

Ultimately, if you’re looking for a way to distribute a WordPress plugin that uses Composer without continuous integration, this is a way to do it.

I recognize, though, it’s a specific use case and thus has a specific solution.


Leave a Reply