Yesterday, I came across a comment that was in the context of a larger post that I think does an excellent job of highlighting what we – as theme developers – should be doing with our projects rather than what we’re currently doing.
For those who know @Rarst, this wisdom will come as no surprise, but for those of you who are new to theme development, or WordPress development of any kind, then I think you’ll find this insightful:
We can chuckle and point fingers at bundled plugin monstrosities. But the reason those monstrosities exist include WordPress strategically for years disregarding need for third party infrastructure and dependency management. It’s telling that it has been priority so low, that even backwards compatibility was broken on related parts of core without a second thought.
So how does this translate, exactly? That is, what is it that we’re doing or that we can do in order to make theme development, plugin development, or both much stronger, resilient, and generally better than what we’re doing now?
Before I start sharing my thoughts on this, I’ll be the first to admit that I’m someone who has been weak on this front and it’s something that I’m making a decision to change (with the very theme on which I’m working right now).
All of us have themes that have dependencies – be it something like a front-end framework or be it something like third-party plugins – but the way in which we’ve gone about managing them leaves much to be desired.
Dependency Management with WordPress
This isn’t really bad, but it’s not ideal. Instead, this is precisely where we should be using some form of dependency management.
First To Dependencies
Of course, this raises additional questions. Namely:
- How do we pull in these dependencies?
- We need a way to make sure that these files are set in the proper location on the file system
- …and more
But how do we go about doing that? There are a number of tools that are available for scripting this kind of stuff. Some of them include TGM Plugin Activation, CodeKit, Bower, Grunt, and Composer. Granted, each one has its own unique purpose, these are the tools that you’re going to want to look into if you opt to begin doing a better job with dependency management.
Secondly, this also raises the question as to why we need to be doing this? That, what advantages are there to managing all of these dependencies?
Generally speaking, most tools will give you the ability to select how granular you want to go when pulling in dependencies – that is, do you want to pull in every commit, every tag, every stable version, etc.
This means that you don’t have to go out and manually download all of the third-party tools that your theme or plugin uses in order to power itself. Instead, you get to script the process such that the best version of the dependency for your project is retrieved.
This way, you aren’t stuck manually dragging files around your file system and then running them through other tools to minify, combine, compile, or whatever else in order to get them working with your theme.
Then To Testing
But with this luxury comes a new responsibility – automated testing. It’s easy to read (and to write) about all of the reasons this is something that we should be doing, but whenever you’re automatically pulling in third-party software that interfaces with your software, you can’t be guaranteed that it’s going to fit in seamlessly.
And just like you’re no longer in the process of manually dragging files around your file system to structure your theme how you’d like, you no longer are stuck having to run down a checklist or a spreadsheet of each element that needs testing. Instead, you can script that to run, say, each time a new build is generated using the aforementioned build tools.
Sure, you’ll still have to setup the initial tests just like you’ll have to setup the initial scripts to retrieve your dependencies but the time that’s saved and the code that’s covered can be generated and evaluated much faster whenever it’s automatically run after a build.
Why Do Any Of This?
Finally, I think it’s pretty common to ask “But why? Why should I bother doing this automatically rather than manually?” For anyone who has worked with third-party code and knows the problems that can come when you’re managing everything on your own, you likely already feel the pain just thinking about it.
For those that haven’t done this before, think about it this way: Each time that you release a version of your project that includes third-party code regardless of if its a plugin, a front-end library, or some other back-end code, you’re introducing a level of complexity to your project and a number points that could have unintended consequences or could result in a number of points of failure.
Using a package manager to retrieve dependencies should ideally have you retrieving packages that are not only registered with the package manager but that are also undergoing the same process as your code – that is, they are tested, they are tagged, released, marked as stable (or not) and so on. This leads to higher quality software all around because the tools that you’re using to retrieve the dependencies can manually do a lot of the manual work for you, but can also automatically test it prior to releasing it.
And, as mentioned, this also absolves you from having to manually go out and retrieve files and rework the whole process again.
Sure, there are other advantages and reasons for using automated tools like this many of which are content for another blog post, but the conversation about the quality of themes seems to come up again and again and it’s something that can be fixed and can be addressed.
We just need to have people using the right tools and processes in order to do it.