Talk:Composer/For extensions

"Nested" composer.json
Some extensions (well, only Wikidata and GoogleAPIClient basically) have multiple composer.json files, or keep theirs outside the "root" of the extension. The usage of such extensions is hopefully documented on their own pages, but perhaps developer documentation should be expèanded to cover this use case/how-to as well? nemobis@tools-login:/shared/mediawiki/extensions$ find -mindepth 3 -type f -name composer.json ./Wikidata/vendor/wikibase/data-model-serialization/composer.json ./Wikidata/vendor/wikibase/data-model/composer.json ./Wikidata/vendor/wikibase/serialization-javascript/composer.json ./Wikidata/vendor/wikibase/data-model-javascript/composer.json ./Wikidata/vendor/wikibase/easyrdf_lite/composer.json ./Wikidata/vendor/wikibase/javascript-api/composer.json ./Wikidata/vendor/wikibase/internal-serialization/composer.json ./Wikidata/vendor/composer/installers/composer.json ./Wikidata/vendor/serialization/serialization/composer.json ./Wikidata/vendor/data-values/geo/composer.json ./Wikidata/vendor/data-values/common/composer.json ./Wikidata/vendor/data-values/validators/composer.json ./Wikidata/vendor/data-values/number/composer.json ./Wikidata/vendor/data-values/time/composer.json ./Wikidata/vendor/data-values/data-types/composer.json ./Wikidata/vendor/data-values/javascript/composer.json ./Wikidata/vendor/data-values/serialization/composer.json ./Wikidata/vendor/data-values/interfaces/composer.json ./Wikidata/vendor/data-values/data-values/composer.json ./Wikidata/vendor/diff/diff/composer.json ./Wikidata/extensions/Wikidata.org/composer.json ./Wikidata/extensions/Wikibase/client/composer.json ./Wikidata/extensions/Wikibase/composer.json ./Wikidata/extensions/Wikibase/lib/composer.json ./Wikidata/extensions/Wikibase/repo/composer.json ./Wikidata/extensions/ValueView/composer.json ./Wikidata/extensions/PropertySuggester/composer.json ./Wikidata/extensions/WikimediaBadges/composer.json ./GoogleAPIClient/lib/composer.json ./DataValues/DataValues/composer.json ./DataValues/DataValuesInterfaces/composer.json ./DataValues/DataValuesCommon/composer.json ./WikidataEntitySuggester/php-client/composer.json
 * As far as I can tell both Wikidata and GoogleAPIClient bundle composer libraries/extensions inside of them, which is why they have composer.json files in sub-directories. Legoktm (talk) 03:04, 19 January 2015 (UTC)

Is using composer still recommended?
I thought that using composer to install extensions is a good idea. This wiki page suggest that it's the way to go, however I discovered now that there are some doubts. If composer is not the way to go, then that should be clearly marked here. Otherwise people invest time to support composer, although a different approach will be recommended soon. Ingomueller-net (talk) 14:43, 4 November 2015 (UTC)
 * Also a related issue: https://phabricator.wikimedia.org/T467

MediaWiki Packagist
Composer support for extensions seems to be deprecated but I really like using Composer to install my extensions so I created a Composer repository that allows you to install MediaWiki extensions with Composer even if they don't have a valid composer.json file. --Rudloff (talk) 10:58, 27 June 2016 (UTC)

Composer-installed extensions can be turned off
I realise that I might be flogging a dead horse here, but I'm a bit confused about why Composer installation of extensions has been deprecated. The reason given is:"the seemingly intractable problem of managing extensions for a Wikifarm when using Composer. A Composer managed extension can only be disabled by removing the extension entirely due to the manner in which these extensions ensure that their entry point file is loaded."

But is this really still the case with new-style ? It used to be true, because the entry point file of an extension would be autoloaded and therefore executed regardless of what was in LocalSettings.php — but now, with all autoloaded files listed in  and no longer any need for an   file, an extension that's installed via Composer must still be explicitly loaded with , mustn't it?

Am I missing something obvious? (I have a bunch of extensions installed with Composer, and it's so much easier for upgrading!)

—Sam Wilson 07:18, 16 December 2016 (UTC)

Still no Composer for extensions?
Is there any chance this RFC could be re-discussed? As several people have pointed out, now that extensions are loaded with wfLoadExtensions, the main reason for closing the RFC is gone.

Composer has become the defacto standard for installing PHP libraries and some other CMS like Drupal are fully embracing it for extensions as well.

I have been using Composer to manage extensions on several wikis (with MediaWiki Packagist) for a few years and it really makes installing them a lot easier (especially if you are using continuous integration).

--Rudloff (talk) 19:31, 6 November 2019 (UTC)


 * I agree, it looks like the original reason for not doing it no longer applies. There are certainly still some extensions that enable themselves directly when they're installed with Composer, but the ones that do this (such as Extension:Maps) are doing it intentionally. All other Composer-installable extensions still need . As far as I can see, the only technical barrier to more extensions being installed with Composer is a way to trigger an update to Packagist when a new release is tagged. Other than that, any extension can choose to set the relevant metadata in its composer.json and register on Packagist; then, it'll be installable. The release can be manually triggered on Packagist. So, yes, maybe a new RFC could be proposed. :-) Sam Wilson 22:07, 11 November 2019 (UTC)