Thoughts on Official Composer Integration

I’ve spent the last couple years at a new job with two WordPress sites under my supervision. I’ve went through the plumbing a bit, removed a god awful Tailwind theme and worked through building new modules and blocks. I’m using Timber/Twig and have composer hacked in relatively painlessly by using the must use plugin in directory and picking filename “00_autoload.php” to force composer to load before anything else. Many years ago I worked on testing the composer integration into Drupal 8.

I’ve been spending some time with plugins and blocks as they currently stand in the ecosystem and trying to figure out how best to integrate composer as an option for those plugins that want to use them. The largest stumbling block is composer has no way to handle library versioning such that two versions of a library are simultaneously loaded. This can lead to a situation where two plugins want two different and incompatible versions of the same library. Drupal’s solution has been to force everyone to update things and be stingier with backwards compatibility grants. That runs against the grain of what I’ve observed in the WordPress ecosystem

Aside – I’m not advocating either approach here, just noting the differences. Each approach has benefits and drawbacks that can be debated endlessly, but are ultimately off topic.

Blocks have had their loading system updated at some point between 5 and 6 (Before my current job I hadn’t worked with PHP, much less WordPress, for 6 years). The current recommended system, with the block.json file, is very powerful and I’ve enjoyed using it. I think moving to a json file declaration for plugins that want to opt into composer makes sense because such plugins will be required to have a composer.json file. The specification is here: https://getcomposer.org/doc/04-schema.md

It might make sense to use the name plugin.json for files using this dialect. In addition to composer directives, hook directives similar to those in the block.json file would be used. Off the top of my head something like this

{
  "hooks": [
    { "name": "class/function invoked" },
    { "init": { "MyPlugin\\Hooks", "init" }}
  ]
}

Plugins could also specify their priority. There are plugins out there that exist for other plugins to build on without exposing their own features, these are more suited to composer libraries.

Finally themes and blocks could invoke composer libraries as well.

The reason to handle this at core is to prevent redundant library loading. As for core code itself, this could be used to firewall off old from new and perhaps work towards a refactor that is enormously overdue and make it possible by breaking things into shards that can be reasoned out piecemeal over a couple years (cause it will take years)

Thoughts?