A very basic introduction to Composer explaining its purpose and how you can use it to take advantage of autoloading.
Although I think the title of this series and the articles for each are clear enough, there are other things I’m aiming to do with this series in contrast to the other series I’ve written up to this point, too.
Specifically, two of the things that I’m trying to do is to two:
Since this is membership content, I don’t mind it being a bit longer than usual, but I also don’t want it to be so long that it’s hard to follow. I’d rather it be a short read with something practical that you can implement after reading each post.
And one of the things that greatly helps with writing better WordPress code is Composer.
If you’ve read this blog for any length of time, then you know that I’m a fan of Composer (however I’m far from the only person working in WordPress who is).
And though I’ve written some material on it, I’ve not written something with the specific aim to get you up and running with it by the end of reading a single, short article.
To that point, we’re going to need to make some compromises: Namely, I’ll provide a sample configuration file along with a way to organize your plugin’s directory. Then, in the next post, I’ll explain some of the features of Composer.
There’smuch more to Composer, and I highly recommend reading the documentation for it. Some of this I’ll cover when looking at the tools I plan to cover later in this series but, for now, I recommend getting familiar with some of the conventions.
Oh! 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.
In the next post, I’ll talk about why. Some people do it, and that’s okay, and I’ve done it before, but it’s important to be judicious about when you do.
Err on the side of not doing it. And I’ll explain why in the next post.