Practical WordPress Development

A Case For Dependency Management with WordPress

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?

I’m Guilty

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

For starters, let’s say that we’re working with Bootstrap – the entire framework – on a theme and we’re going to include all of the CSS and the JavaScript in our theme. Typically, I think many of us download the packages, drop them into directories in our theme, and then enqueue them using the WordPress API.


Arguably the most popular front-end framework (but certainly not the only one :).

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?
  • If we end up using a tool to pull these dependencies into the theme, we need a build process to compile the Sass and lint and minify the JavaScript
  • 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 ActivationCodeKit, 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.

CodeKit: One tool for dependency management.

CodeKit: One tool for 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.


  1. Luke

    If you’re the type of guy or gal who’s tipping your mind toes into forward thinking pools of thought like dependancy management for WordPress then you’re already ahead of the pack. Please don’t shy away at the first cold touch of complexity and leap back into the safety of the ‘I do just fine without x’ attitude. Theres a reason the rest of the developer community came up with tools like composer, bower and gulp, it’s not just to mess with ya. They solve real problems. Hey my little forward thinker, don’t be afraid, keep looking at the water. You’re thinking of getting wet anyway, might as well skip the torturously slow tiptoe in and bomb right into the deep end.

    Check out how uses composer to handle dependancy management for WordPress, and how uses bower to handle dependancy management for themes.

    No, don’t look back at the turtle WordPress culture urging you to stay out. To hell with them. They just come to the developer career beach to stay safe in their beach chairs, they never get their feet wet. Jump! We’ll be waiting for ya. The water’s lovely this time of year! It’ll be worth it my friend. I promise.

    • Jimmy Smutek

      Check out how uses composer to handle dependancy management for WordPress, and how uses bower to handle dependancy management for themes.

      +100 – I immediately thought about Roots, with Sage and Bedrock, when I read Tom’s post. I can’t think of a better example of a project that’s been on top of all of this new fangled stuff. Sage 8.0 looks so incredibly slick. I just checked out the new workflow video that Ben posted and I can’t wait to get in there and play around.

      I’ve been back and forth between Bones and Sage for my work, but its Roots that has had the biggest impact on my learning , my efficiency and the quality of my work. The various Roots projects have always pushed me to learn new things (even when I wasn’t comfortable with them) over the last 3 or so years. LESS, Sass, Grunt, Gulp, Bower and Yeoman all come immediately to mind as technologies I dove into as a direct result of using Sage.

      Speaking of Yeoman, I can’t wait to see the generator that they come up with.

      Sorry, a bit off topic there. But yeah, I second the suggestion to look into the Roots projects. :)

    • Greg

      Well said. I know many people that are afraid of one or another type of automation tool. They are saying stuff like: “I don’t want to loose control over my code” or “That Bower is stupid, can’t I just download source code?”.

      Just try them and give them a chance. At first it might not make any sense to use for example Yeoman to create new project, but when you get a hang of it you will be able to generate base of any web app in seconds.

      Nowadays web development becomes more and more complex, and to deal with it all we got an amazing set of tools, just embrace it and move on.

  2. Scott Fennell

    Very nice post, Tom. It’s always good for us WordPress folks to survey the broader landscape and incorporate new tools into our work. However, unless I am mis-reading, I think your post is missing an important caveat: It’s always best to defer to core for scripts when possible. Indeed, that’s a rudimentary form of dependency management in and of itself.

    So, for example, let’s say a theme developer bowers a version of jQuery that is different from what core is using. That could have devastating consequences for the plugins trying to do their job on that install.

  3. Timothy Brand

    Honestly I’ve always built my themes where I have to manually update everything. I recently started using the CDNs for my frameworks, but even that has holes. I’ve been hearing a lot about these compiler programs and I’ve never taken the time to investigate or learn to use them. I think it’s about time now. I want to do what’s best for my clients and the community. Thanks for the post, I’m going to keep it for reference.

  4. Dwain

    I totally agree. We need to address this, no matter how difficult it may be. It is time for a leap toward automation and increased WordPress developer productivity in general.

  5. Alexander

    Build systems and package managers take some getting used to but the advantages they offer for ongoing development are too good to pass up. I like the work Roots has been doing with Sage and Bedrock in this area. I have also been messing around with my own Gulp-based build system which might be of some interest to people here:

    One thing I’ve been experimenting with recently is breaking themes down into their component parts and re-assembling them the same way we work with front-end stuff. Plenty of starter themes are packed with boilerplate normalization functions; little snippets of code to clean up the cruft. What if we followed the Node way and turned out a whole bunch of bite-sized, easily understood theme components that could be readily consumed by a package manager like Composer? Say you’re starting in on a new theme and you want to add a bunch of the usual boilerplate plus the plumbing for an AJAX contact form. Install a few components from the command line, wire them together with a bit of custom markup, rebuild the theme, and you’re ready to roll. TGM Plugin Activation accomplishes something similar… but in this case I’m thinking about the small-scale bits and pieces that usually end up in most of our themes. Anyway, it’s an interesting thought experiment for now.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑