Instead of requiring developers to explicitly put autoloads in extensions.json, PSR-4 should be used.
For example, if I put the methods for hooks in the HitCountersHooks class and the HitCountersHooks.php file contains that class, I should not have to specify the following in extension.json:
"AutoloadClasses": {
"HitCountersHooks": "HitCountersHooks.php"
}| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable using PSR-4 autoloader for MediaWiki core and extensions | mediawiki/core | master | +112 -17 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Legoktm | T99865 Extension registration should support using a PSR-4 autoloader | |||
| Resolved | Legoktm | T173799 Implement a PSR-4 autoloader in MediaWiki core |
If namespaces are used then the methods could be put in the class referred to by HitCounters\Hooks and it could be found in _\_DIR__/Hooks.php, where _\_DIR__ resolves to the directory for HitCounters' classes.
We could either implement this by having ExtensionProcessor convert psr-4 --> classmap and then cache that, or just have a psr-4 autoloader in core. For either, we should look into how much we can re-use from composer (https://github.com/composer/composer/tree/master/src/Composer/Autoload) and the psr-4 example autoloaders (http://www.php-fig.org/psr/psr-4/examples/).
As we have seen in the WMF cluster (T85182), using an autoloader that stats files rather than a fixed classmap can actually cause a measurable performance problem on a highly loaded wiki. If maintaining the static classmap is somehow onerous maybe we can make some tools to help with that instead? We do have the generateLocalAutoload.php for such things in mw-core.
PSR-4 may not be appropriate for some circumstances (e.g. WMF Cluster) but that doesn't mean it shouldn't be used. It should be possible to use explicit paths if given but "fall back" (unless otherwise configured) to PSR-4 for development.
FWIW, my understanding is that Composer creates an static autoload file as a cache, not to be checked it, but I haven't verified this.
composer supports this; the merge plugin for composer is included in core; the merge plugin supports merging the composer.json from extensions if the value "extensions/*/composer.json" is added to its config. No need for extension registration to do any autoloading.
Should we add "extensions/*/composer.json" to the merge plugin config in core (i.e. merge https://gerrit.wikimedia.org/r/#/c/218987/ )?
Once MediaWiki core has a PSR-4 autoloader, we can add a "AutoloadNamespace" property or something to extension.json to allow extensions to use it.
Change 373626 had a related patch set uploaded (by Legoktm; owner: Legoktm):
[mediawiki/core@master] [WIP] Enable using PSR-4 autoloader for MediaWiki core and extensions
https://gerrit.wikimedia.org/r/373626
This has become critical for Wikidata - without PSR-4 support, we have to maintain long lists of classes manually in extension.json. That's pretty painful...
Is there anything we can do to move this forward?
There should be no need to do it manually. For Wikibase there's a script that re-generates the autoloader. Also, Wikibase still isn't using extension.json, so this isn't much help yet. (I plan on tackling the extension.json migration once the build is dead). For some of the smaller extensions that had a small number of classes or that weren't actively being developed we implemented a manual classmap but it would be easy to write the script for those if it was really wanted.
Is there anything we can do to move this forward?
Luckily, this was already in my list of things I planned on doing this week. I need to update the patch based on what I discussed with Tim.
Change 373626 merged by jenkins-bot:
[mediawiki/core@master] Enable using PSR-4 autoloader for MediaWiki core and extensions
https://gerrit.wikimedia.org/r/373626