fedi.jeremy.hu

@jeremy That’s definitely something worth covering! The series outline is very flexible. I will cover the basics first and unit testing will be a huge and complicated thing. Maybe after that would be a nice place for covering composer packages!

Thanks for reading and your kind words!

@jeremy I'd be curious how you ended up with your solution and why it was chosen over the namespace rewriting tools like https://github.com/coenjacobs/mozart because that is what I ended up with for my work and my recent talk at #WCVIE https://kraftner.com/talks/managing-your-dependencies-in-wordpress/

@kraftner It's been a few years now, but I do remember us looking at PHP-Scoper, and Mozart, when we started working on extracting some of Jetpack's features into Composer packages.

Ultimately we went in a different direction because we had a different goal: instead of having different (prefixed) versions of a package loaded on a site, we wanted to have the site always load the latest version of the package available on the site. This ensures that a site with a plugin that hasn't been updated in a while doesn't hold other plugins back with its outdated packages.

This is a different approach that wouldn't work for everyone, but that has its advantages when you have a tight control / overview of all the packages you require, and can ensure that backwards compatibility / breaking versions are properly handled.

That must have been an interesting talk. Do you know if it's on WordPress.tv already, I'd be curious to watch it!

@jeremy @kraftner Is it not true that your( Automattic's autoloader ) solution only 'works' if all plugins happen to use it?

BTW I use Namespacer (Interfacelab ) which I found much simpler than PHPScoper - ironically I had to fork as there is small issue created by Action Scheduler that I needed to resolve (and there seems no active development on Namespacer ).

@alan @kraftner Right, since Jetpack Autoloader does not prefix like PHP-Scoper does. If there are other instances of a package that are loaded via a different autoloader, there will be conflicts between classes that have the same name. This is the same problem you'd get with other autoloaders really.

In an ideal world, we would have a common autoloading solution for all of Core and we could all use it, but that's another topic / can of worms :)
Until then, I'm afraid we all have to find a way :)

@alan @kraftner To avoid potential conflicts, we suggest the use of the Jetpack Autoloader in the different packages used by Automattic plugins that use Jetpack Autoloader, so other folks wanting to use those packages in their plugins know that using Jetpack Autoloader with that package is recommended.

e.g. the Assets package:
https://github.com/Automattic/jetpack-assets/blob/trunk/composer.json#L15

@jeremy Oh so you only split up your own code into packages but do not use 3rd party code? If yes then this might actually be smart since it keeps the memory footprint low by not duplicating all dependencies. I'm coming at this issue more from the angle of using 3rd party code so I don't need to reinvent the wheel. Stuff like e.g. DI-Containers.
The talk unfortunately wasn't recorded but pretty much all I said should be in the talk notes included in that slides.

@kraftner We use very few third-party packages indeed. 👍

Thanks for the link to that Autoloading in core PR; I had missed it!

@kraftner @jeremy yes makes sense if your product is a set of your own libraries, but yes the main issue I have faced is third party SDKs, like Stripe, that are often not compatible between versions, so if you are unlucky another plugin has already loaded an incompatible version ( possibly via includes, not really an auto loader issue ). Good libraries built specifically for WP do check their own versions and normally are forward compatible in the WP way, it is the non WP built SDKs that break.

@alan @jeremy Yeah in that case you're better of with the namespace rewriting approach of tools like https://github.com/coenjacobs/mozart

@jeremy @kraftner Yes -can of worms maybe - it would have to be a community security curated directory of libraries,rather like the plugin directory, with no need for plugins to have local libraries. Not unlike the way core includes jQuery library and plugins are meant to use that.

@alan @jeremy On the topic of autoloading with WP: There actually seems to be some movement again: https://github.com/WordPress/wordpress-develop/pull/3470
Although not related to plugins and themes (yet)