You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A disadvantage to using Composer at the plugin level is if multiple plugins are running the same dependency, it will load in each of those versions separately. Of course, this is great when there are different versions, however, it can be wasteful if multiple plugins are using the same version of a dependency in a plugin.
On personal projects that do not distribute, I have been putting composer dependencies for all of the plugins and themes on that site in a single composer.json in the mu-plugins directory, and then requiring the autoloader as a muplugin.
This is nice because it sets up the autoloader before the plugins get loaded in, and provides a relatively straightforward way for multiple plugins to use dependencies for the same version.
However, updating plugins is still a very manual process, as everything that uses those dependencies needs updated and tested should I need to upgrade to a newer version. This creates a barrier since there's potential for extensive additional testing to be implemented just to use a newer version of a plugin.
If it were possible to configure multiple namespaces in Mozart, I think this problem could be resolved at the mu-plugin level. With that, you could theoretically create multiple namespaces for different versions of a dependency that needs to run on a single installation of a site.
I would consider my next statement out of scope for this issue (and perhaps Mozart, altogether) but from that, you could potentially build a script that gathers up all dependencies from the composer.json files in each active plugin, and generate all dependencies across plugins on a site.
The text was updated successfully, but these errors were encountered:
A disadvantage to using Composer at the plugin level is if multiple plugins are running the same dependency, it will load in each of those versions separately. Of course, this is great when there are different versions, however, it can be wasteful if multiple plugins are using the same version of a dependency in a plugin.
On personal projects that do not distribute, I have been putting composer dependencies for all of the plugins and themes on that site in a single
composer.json
in themu-plugins
directory, and then requiring the autoloader as a muplugin.This is nice because it sets up the autoloader before the plugins get loaded in, and provides a relatively straightforward way for multiple plugins to use dependencies for the same version.
However, updating plugins is still a very manual process, as everything that uses those dependencies needs updated and tested should I need to upgrade to a newer version. This creates a barrier since there's potential for extensive additional testing to be implemented just to use a newer version of a plugin.
If it were possible to configure multiple namespaces in Mozart, I think this problem could be resolved at the mu-plugin level. With that, you could theoretically create multiple namespaces for different versions of a dependency that needs to run on a single installation of a site.
I would consider my next statement out of scope for this issue (and perhaps Mozart, altogether) but from that, you could potentially build a script that gathers up all dependencies from the
composer.json
files in each active plugin, and generate all dependencies across plugins on a site.The text was updated successfully, but these errors were encountered: