Bundling libraries is not overhead, it’s a best practice

It’s been a while since I last posted something about the whole dependencies horror that I’m still trying to deal with in the WordPress ecosystem. Justin Sternberg’s post on the future of the CMB2 library got the discussion going again and soon after, we were at the dependencies discussion again.

It was mainly the discussion about overhead in bundling code that made me want to write a long reply, because I disagree with this quote:

What I hate is seeing someone use cmb2 when their own plugin is ten lines. But that’s them not understanding libraries and weight.

This post started as a comment on Justin’s blog post, but I figured it would make a lot more sense as a post on my own blog as it covers a lot more than Justin’s initial question about CMB2. Here goes…

Well abstracted, clever code

I would argue that if a framework enables me to write a plugin in 10 lines that utilises a framework so efficiently that my plugin actually passes the .org plugin guidelines, this can mean two things. Either the plugin guidelines (there is a rule that defines the minimum functionality, if I recall correctly) are terrible, which they are not, or the framework code is very well structured and easy to use.

Well maintained and tested libraries

The problem here is not the bundling of libraries. This is actually a really good thing. Code that I’m bundling, is not my responsibility. I have less code to maintain, assuming the library itself is well maintained and tested. This is also a group effort really, as all developers who implement the framework can contribute back to it. Any fixes, improvements or new features will benefit all the plugins that implement the framework.

This is not overhead. This is what dependencies are designed to do. I write PHP apps of just a handful of controllers and models, based on the Laravel framework. Laravel itself pulls in a ton of Symfony components and so on. All this enables me to quickly write web apps that do what I want them to do and I get to use all this awesome code that is already available. My web apps are sometimes maybe 1000 lines, while all the bundled components are much – MUCH – more code.

The biggest problem (at least in my opinion) with the WordPress ecosystem is the whole dependencies thing. Something like CMB2 would be a perfect dependency for a lot of plugins. Making it a dependency that is easy to bundle, easy to maintain and update, is a pain in WordPress right now. The focus on ‘always run the latest and greatest version’ and ‘never make it impossible for users to update’ is great and all, but we can’t continue to do this without solving the dependencies problem.

A WordPress-y solution to this problem

Effectively rolling out updates of dependencies and resolving conflicts is the hard part of this puzzle. That’s what we need to solve in our own WordPress-y way.

Composer has solved this problem for the PHP ecosystem in general. I’d like to see ways that we can use Composer in our ecosystem as well. If that’s impossible, we should look at how Composer solves the problems it solves and mimic that in our own way for just the WordPress ecosystem. This will greatly benefit the end users as well, we just need to figure out a way to make this as user friendly as possible.

Join the Conversation

1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *