XF 2.2 Add-on composer loader support & development mode

Xon

Well-known member
With the new caching of composer paths; in development mode if a developer changes packages for an add-on which adds (or removes!) a auto-loader type (namespaces/psr4/classmap/files), then it requires a number of hoop jumping for XF to detect this.

It looks like when updating/removing composer packages; for reliable operation either the addon.json must be updated and then imported via xf-addon:sync or xf-addon:update, or the more heavy-weight xf-addon:rebuild. Which may require disabling listeners in the case of removing a composer autoloader type.
 

Chris D

XenForo developer
Staff member
To a certain extent, even before the recent changes, these kinds of steps would have been required already. Such as if you were adding a new composer dependency to an add-on that didn't have one before.

The active add-on cache (which rebuilds the composer info) can be rebuilt (for all add-ons) by disabling and then enabling any add-on.

Although potentially the quickest way of triggering it is with a single xf-dev:rebuild-caches command. I don't think that's particularly onerous.
 

Kirby

Well-known member
I am not entirely sure if I fully understand (the advantages of) the new approach:
The existence of autoload_*.php files is being checked when rebuilding registry addOnsComposer, the result is stored is storeed there and used att runtime to require those files without existence checks.

This does save the existence checks at runtime which is an improvement :)

That still means though that usually 3 tiny PHP files will be required at runtime for every Add-on that does use composer support - quite often the namespaces and classmap files effectively will do nothing (eg. return just an empty array).
(Of course Add-on developers could manually optimize this a bit by removing those files - but who does that?)

So what's the point of continously loading them, wouldn't it be a lot better to just compile all psr4/namespaces/classmap/files data when rebuiding this registry and using that data at runtime (either stored there as JSON or as PHP code in code-cache?
IMHO this could further improve performance, especially for users that can't use shared memory OpCache and/or have to enable opcache.validate_root/opcache.validate_permission/opcache.validate_timestamps
 
Last edited:

Chris D

XenForo developer
Staff member
I am not entirely sure if I fully understand (the advantages of) the new approach
Well, it's this, which resulted from a bug report you posted
👇
This does save the existence checks at runtime which is an improvement :)

As for everything else we're definitely in the realms of micro-optimisation.

A typical XF page already includes nearly 300 included files through our own classes and vendor packages. Shaving off a few more per add-on will make a difference so small it's not something I'd contemplate spending any further time on.
 
Top