Last week, I wrote a short post asking What Is the Vendor Directory? which yielded a number of great responses, but it also resulted in a number of different questions, all of which were related, but none of which could be covered in that specific post.
For example, the article asked?
- When do I know when to use a
libdirectory versus a
- Should the
- What about an
And though some of these were answered in the comments and some of these answers can be found elsewhere, it did result in another question about the
The Assets Directory
Regardless of what package manager you use or how you opt to organize your files, you’re likely familiar with having an
assets directory. How you opt to use this directory is likely different than how someone else uses it, though.
In other words,
lib usually have slightly stricter guidelines or are generally used in the same way than something like
And if that’s the case, then how do we come up with any type of rule of thumb to follow when we want to use
assets especially in conjunction with
Before looking at a way to actually organize our assets, I think it’s worth trying to come up with a working definition of what a project asset actually is. In our case, we’re going to be talking about WordPress-specific projects (so this will vary if you’re working in another environment).
First, the official definition of asset is:
a useful or valuable thing, person, or quality.
assets directory into which all of the above would live?
Alternatively, couldn’t a case be made that a given library has its own set of assets? For example, think of a front-end framework that includes glyphs, fonts, images, and CSS. Would an
assets subdirectory make since under a
I think a case can be made for that, as well.
Given the previous discussion on
lib, I tend to approach
assets in the following way:
- I’ll create a top-level directory in the root of my project and call it
- Within that particular directory, I’ll have
fonts, and more as seen in the image above.
- Within each of those directories, I may have something like
dev, and so on to represent my unminified, development-based files.
- I’ll have my
jsdirectory then I’ll have a
- In the
libsubdirectory, I’ll include any third-party dependency, say,
acmeand then I leave it intact in whatever way the author built it
Sure, this may result within a nested
assets directory, but the point is to keep the packages as organized, as cohesive, and as self-contained as possible. I don’t want my files mixing with other files.
Secondly, if I write my own library then I will treat it the same way as another developer would and organize the files as such as then drop it in its respective directory.
And finally, since
vendor tends to be something included as a dependency via a package manage, I also treat it like a black box – however it’s organized is how it stays.
Organizing Your Assets
Ultimately, I think for your own work, having a top-level
assets directory in the root of the project makes sense, and then leaving the organizing of
vendor intact is the easiest way to maintain the code based on how your code and other third-party code is written.
But I’m also curious how the rest of you opt to approach this. So, as with the
vendor directory conversation, feel free to share your thoughts in the comments.