I guess it does the job. However it makes the task of extension developers more error-prone. For the very least, it should be documented clearly (here?).

@saper: the problem with autoloading are use cases where the code of many extensions/skins should be deployed, but only part of them should actually be used. See the "wikifarm" use case here and here. If extensions/skins do not autoload (as in calling wfLoadExtension themselves), then one can choose in his/her LocalSettings.php, which ones one wants (using require_once or wfLoadExtension as appropriate for the extension in question).

In T88596#1786388, @bd808 wrote:

I added https://www.mediawiki.org/wiki/Composer#Using_composer-merge-plugin

In T88596#1786284, @MarkAHershberger wrote:

As seen on the github issue, when I explained what wiki farms need from
composer -- enabling or disabling extensions based on the wiki being
used from a single code base -- the scenario was dismissed.

The alternative suggested was to have a different mediawiki installation
for every wiki.

With the developers of composer being unwilling to adapt it to
multi-site use cases like a wiki farm, I agree with the developers:
composer isn't suited for managing MediaWiki extensions.

Thanks for the explanation! Is this documented somewhere? Since the mechanism is already used in REL1_25, which is out, it would be good to have documentation for it...

How does the plugin know which composer.jsons to take into account? Does the admin have to populate the include property in his composer.json manually or will the composer.local.json be generated somehow?

I am with @JanZerebecki and @bd808: To me it looks like disabling some extensions selectively is attacking the problem at the wrong end. I think that an extension should not be loaded (in the sense of wfLoadExtension) when it is installed with composer. In particular, this means that composer.json should not autoload the file ExtensionName.php. Rather should composer only be used to merely install the files, then the extension would be activated in LocalSettings.php using wfLoadExtension('ExtensionName') or require_once "$IP/extensions/ExtensionName/ExtensionName.php".

I just thought of an argument why using composer and another dependency manager at the same time might be a bad idea, at least if they are agnostic to each other.

@MarkAHershberger, can you be precise about what was the argument against using composer only in the discussion on github?