With the rise of package managers, build tools, and other similar software being brought to WordPress, we’re seeing more advanced directory structures in both our themes and our plugins.
Some of these tools have been around a long time – at least in one form or another – as it relates to software development, but it’s still relatively new with respect to WordPress.
If you’re new to WordPress development or you’re new to some of the various tools we have at our disposal for working on these types of projects, then it’s easy to get overwhelmed with some of the organizational choices of said projects.
Relax: that’s normal. It’s a natural part of the learning curve.
Though there’s a lot that can be talked about with respect to all of this, I thought it might be worth tackling just one aspect of it in this particular article.
The Vendor Directory?
When it comes to working on projects, most of them are going to include some type of third-party libraries.
To that end, we’re likely used to seeing a
lib directory in our projects – maybe we’ve created it, maybe someone else has. So before we talk about a
vendor directory, it might be worth clarifying what a
lib directory contains and then how a
vendor directory differs.
Perhaps the best way to define the
lib directory is understanding what a library is and how it relates to the overall project:
Normally, a library refers to third party-code.
Simple, right? As mentioned, this may be something that’s basic as CSS or something as complex as an involved PHP library that works with the file system.
Whatever the case, we often think of a library as a black box – we import it into our project and use its APIs or its features as needed in order to help make our work.
Ultimately, we’re trying to leverage the work of someone else who’s provided a specialized solution for a problem that we’re currently facing.
This is where it gets a little bit more confusing (because why would anything in programming need to be as clear as possible?).
vendor directory might be treated the same way as a
lib directory. That is, you may end up seeing it used in place of
lib, but that’s not the only way it may be used.
One way to think of the `vendor` directory is as a more generic form of `lib`.
Whereas a library is usually third-party code,
There are also other ways in which the directory may be used, as well.
`vendor` is also used as a way to track code that’s supplied by the vendor – or the author – of the framework in question.
When it comes to WordPress, we won’t really see this since we’re building things on top of WordPress.
If, however, you’re working in the context of another framework and it includes a number of different assets and other tools that are made available to us, as the developers, then this code would rely in the
vendor directory, too.
But This Raises More Questions
Though the above points seek to make it a little easier to understand how files are organized when working with web applications, each foundation, framework, or other device will have its own idiosyncrasies.
Although I’ve attempted to provide a basic rule of thumb for each that tends to be the most common case, it’s not a hard and fast rule. It’s more of a guideline than anything else.
Even still, this should help to clarify some of the organizational structures that we see throughout a code base when working with or writing a project.
But maybe not. Maybe it actually raises more questions:
- When do I know when to use a `lib` directory versus a `vendor` directory?
- What about an `assets` directory?
- Can `lib` and `vendor` co-exist?
All of these are normal questions and I think I’ll offer a follow-up post that includes more details (especially with respect to an
assets directory and an
Before I do that, though, I’m also curious to hear your take on
vendor as it relates to WordPress themes and plugins so don’t hesitate to share your use of the directories in the comments.