Dependency management for plugins and libraries

[joppuyo]

Many plugin developers use Composer to manage PHP dependencies in their plugins, however, this may cause hard-to-debug issues if two plugins use the same library. Because of how Composer works, it will only load one version of that dependency at a time. Imagine the following scenario:

Plugin Developer 1 creates a plugin named Foo that uses version 2.0 of a library Bar
Library Bar developer releases version 3.0 of their library which renames function get_baz() to get_qux().
Plugin Developer 2 creates a plugin name Quuz that uses version 3.0 of the library Bar

User installs both plugins at the same time. Now their site crashes because one of the plugins calls a missing function.

There are some ways developers have worked around this, for example using ​https://github.com/coenjacobs/mozart , ​https://github.com/TypistTech/imposter-plugin or ​https://github.com/humbug/php-scoper which add an extra unique namespace to files defined as Composer dependencies but these tools are error-prone and don't work if the library checks dependencies in runtime.

I think it could be great to have some sort of way to fix this in the core. According to the Composer developers, Composer was never meant to be used on plugin level, only at the project level where each plugin would be its own dependency and Composer could calculate any dependency conflicts run time.

I think two ways to fix this would be:

1. Install WordPress (and its plugins) using Composer like Drupal does ​https://www.drupal.org/docs/extending-drupal/installing-modules . I think this would be the best way to fix this but it's not really that great if the majority of WordPress installations are on shared hosting and can't run composer. Drupal has a thing named Ludwig ​https://www.drupal.org/project/ludwig which works from the Drupal admin interface and allows you to manually download and install the required dependencies.

2. Distribute libraries on WordPress.org plugin directory. This used to an option but now libraries are disallowed in the plugin directory ​https://make.wordpress.org/plugins/2016/03/01/please-do-not-submit-frameworks/ . If libraries would be distributed on WordPress.org, you could at least check if the library is the correct version in your plugin before using it. There's also the issue of ownership, who will upload the libraries and keep them up to date?

Without any solution to this plugin developers who want to use libraries will have to use workarounds or simply hope that users do not install libraries with different versions. Please note that this issue is not unique to Composer, you can run into the same problem even if two plugins require the library manually.

Some more info about this issue is in this blog post: ​https://deliciousbrains.com/php-scoper-namespace-composer-depencies/

[TimothyBlynJacobs]

Hi @joppuyo,

Welcome to trac! This is a conversation that is already being tracked in #22316. To keep the discussion all in one place, I'm going to close out this ticket. I'd invite you to post your thoughts in a comment on the existing ticket.

[joppuyo]

Thanks, I'll do that.

I did try to search for any duplicate issue before creating this one but unfortunately, I did not come across that one.

[anonymized_14808221]

The thing is, _that_ ticket did not address _this_ issue.

https://core.trac.wordpress.org/ticket/22316 > handles _plugin dependencies_ as in one plugin requiring the other.
This very ticket asks for _composer dependency_ management. Which is as far I see not part of the other ticket, or got missed.

However looking at the (heated) discussion that unfolded in that ticket in regard... I guess this will just never come into core.
The way to resolve this would be to have a _core composer file_ the developer can update to request dependencies for their plugin, and core would define the version range, so conflicts would be avoided, and anyone who does NOT want to use those versions has to bundle themselves _and prefix_ their dependencies.

Sort of when using jQuery libraries that are in core vs bringing your own.

I am setting this to second opinion needed because IMO it should not be closed as a duplicate.