XF 2.2 Add-on composer loader support & development mode

[Xon]

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]

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]

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

 

[Chris D]

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.