Tools for Writing Better WordPress Code: The Composer Lock File Understanding how the Composer lock file prevents us from needing to commit the vendor directory to our repository.

Before wrapping up our discussion on Composer, we have one important thing left to discuss: The vendor directory (and by extension, the Composer lock file).

Specifically, we need to talk about why we don’t need to commit the vendor directory to the repository but how our contributors can be sure they have the latest version of the software needed to work with our code base.

Using code quality tools to write better WordPress code is important, yes, but understanding how to properly manage dependencies and our repository is important, too. So before looking at said utilities, let’s review the lock file, the role it plays, and why we don’t need to commit the vendor directory to our repository.

Better WordPress Code with The Composer Lock File

For those who work with WordPress – and perhaps in other PHP-based frameworks and foundations (I don’t really know since I tend not to work with them) – there is a reliance on Composer, which is a good thing.

This may also lead to wanting to commit the entire vendor directory source control which is not a good thing.

As mentioned in the previous post:

And I don’t recommend checking the vendor directory into your repository. That can become a huge directory later, and it can undermine the whole purpose of Composer.

So how can we make sure that we’re not needlessly committing files (and thus inflating our repository’s size) to the repository all the while making sure our contributors are using the same version of the software as we are?

The Desire to Commit the Vendor Directory

For those of you who have run Composer and are familiar with at least seeing the vendor directory, then you’re likely used to seeing multiple directories of dependencies that are installed.

And they are useful; otherwise, you wouldn’t have included them, right?

Better WordPress Code: The Vendor Directory

But here’s the thing about the vendor directory: even if you just have a few dependencies installed with your project, the filesize itself can be large. And this can be even larger when you have a lot of dependencies.

Regardless, committing this to source control seems to make sense, right? We want to make sure everyone has the same version of the software that we’re using and we want to make sure they don’t have to deal with Composer.

There’s another way, though. And it keeps our repository small while also making sure that the versions of our dependencies are kept in sync with those who clone the repository, commit to the repository, or for any continuous integration utility that uses the repository.

Understanding the Lock File

Before talking about the vendor directory, I want to touch on another important aspect of Composer: the lock file. That is, if you run the install or the update command in your terminal, then you’re going to see a lock file generated along with the vendor directory.

Better WordPress Code: The Composer Lock File

What is this file?

The previous post showed an example configuration file. One of the things this file also allows us to do is to define third-party libraries, or dependencies, that we can use in our projects.

I’ve talked about this in other posts (and we can look at this a bit more later in this series). But this is where the lock file comes into play.

In short, the lock file always contains information on the version – the exact version – of the of the dependencies that are being used with the project the last time that install or update was run.

Better WordPress Code: The Composer Manual

From the manual:

When Composer has finished installing, it writes all of the packages and the exact versions of them that it downloaded to the composer.lock file, locking the project to those specific versions.

You should commit the composer.lock file to your project repo so that all people working on the project are locked to the same versions of dependencies (more below).

The goal is to make sure that every one is running the same version of the dependencies of the project – not older versions, not newer versions – but the same version.

So when you run composer install when a lock file is included in the repository will use the version of the software as defined in the lock file.

And this ensures that everyone is running the same version of each dependency and thus can prevent the need to commit the vendor directory to source control.

Writing Higher Quality Code

So where do we go from here?

Now that we understand how to use Composer and how to use the lock file, we can start talking about actual dependencies that help improve our code quality.

And when we’re talking about writing higher quality code, there are utilities made exactly for that. So in the next few posts, we’re going to look at some of them.