Change Details

**Problem** It is possible for multiple extensions to require the same package in incompatible versions and for one of those versions to be in #mediawiki-vendor. This would work fine until the other package expects the code to work a certain way (and doesn't have a test for it) and then all of the sudden it breaks (since the package is not in a version the extension expects). >>! In T166956#5060213, @dbarratt wrote: > For instance, if you have two extensions `A` and `B`. If `A` requires `guzzlehttp/guzzle` in `^6.0.0` and `B` requires `guzzlehttp/guzzle` in `~6.2.0` Composer will install `6.2.3` instead of the latest version which is `6.3.3`. It does this because `B` has not declared that it is compatible with anything other than `6.2.x`, but `A` is fine with anything in `6.x.x`. If it can't resolve the version to something that is compatible with **everything** Composer will throw an exception and force you to deal with the problem. This is a huge safe-guard against incompatible versions that we are not using, and we are forcing site administrators to deal with on their own. This is amplified by #mediawiki-vendor because the `guzzlehttp/guzzle` version constraint must be manually specified which may become incompatible (over time) with `A` **and** `B` **Solution** Instead of maintaining a repo of dependencies. WMF could instead use Composer to require the extensions they need. This will let extensions define dependencies without having to manually update #mediawiki-vendor. This does **not** mean WMF needs to run Composer in production, they can simply commit the vendor directory in their instance of MediaWiki. For instance, if you were to require the extension like: ``` composer require mediawiki/abuse-filter ``` you would get the abuse filter extension (installed in the `extensions` folder) as well as all of that extensions dependencies installed in the `vendor` directory. WMF could either use a version constraint on the extension, or use `dev#master` which will give them the latest `master` of that extension. This follow's Composer's best-practices and removes the need to manually merge and update dependencies in MediaWiki-Vendor

**Problem** It is possible for multiple extensions to require the same package in incompatible versions and for one of those versions to be in #mediawiki-vendor. This would work fine until the other package expects the code to work a certain way (and doesn't have a test for it) and then all of the sudden it breaks (since the package is not in a version the extension expects). >>! In T166956#5060213, @dbarratt wrote: > For instance, if you have two extensions `A` and `B`. If `A` requires `guzzlehttp/guzzle` in `^6.0.0` and `B` requires `guzzlehttp/guzzle` in `~6.2.0` Composer will install `6.2.3` instead of the latest version which is `6.3.3`. It does this because `B` has not declared that it is compatible with anything other than `6.2.x`, but `A` is fine with anything in `6.x.x`. If it can't resolve the version to something that is compatible with **everything** Composer will throw an exception and force you to deal with the problem. This is a huge safe-guard against incompatible versions that we are not using, and we are forcing site administrators to deal with on their own. This is amplified by #mediawiki-vendor because the `guzzlehttp/guzzle` version constraint must be manually specified which may become incompatible (over time) with `A` **and** `B` **Proposed Solution** Instead of maintaining a repo of dependencies. WMF could instead use Composer to require the extensions they need. This will let extensions define dependencies without having to manually update #mediawiki-vendor. This does **not** mean WMF needs to run Composer in production, they can simply commit the vendor directory in their instance of MediaWiki. For instance, if you were to require the extension like: ``` composer require mediawiki/abuse-filter ``` you would get the abuse filter extension (installed in the `extensions` folder) as well as all of that extensions dependencies installed in the `vendor` directory. WMF could either use a version constraint on the extension, or use `dev#master` which will give them the latest `master` of that extension. This follow's Composer's best-practices and removes the need to manually merge and update dependencies in MediaWiki-Vendor

**Problem** It is possible for multiple extensions to require the same package in incompatible versions and for one of those versions to be in #mediawiki-vendor. This would work fine until the other package expects the code to work a certain way (and doesn't have a test for it) and then all of the sudden it breaks (since the package is not in a version the extension expects). >>! In T166956#5060213, @dbarratt wrote: > For instance, if you have two extensions `A` and `B`. If `A` requires `guzzlehttp/guzzle` in `^6.0.0` and `B` requires `guzzlehttp/guzzle` in `~6.2.0` Composer will install `6.2.3` instead of the latest version which is `6.3.3`. It does this because `B` has not declared that it is compatible with anything other than `6.2.x`, but `A` is fine with anything in `6.x.x`. If it can't resolve the version to something that is compatible with **everything** Composer will throw an exception and force you to deal with the problem. This is a huge safe-guard against incompatible versions that we are not using, and we are forcing site administrators to deal with on their own. This is amplified by #mediawiki-vendor because the `guzzlehttp/guzzle` version constraint must be manually specified which may become incompatible (over time) with `A` **and** `B` **Proposed Solution** Instead of maintaining a repo of dependencies. WMF could instead use Composer to require the extensions they need. This will let extensions define dependencies without having to manually update #mediawiki-vendor. This does **not** mean WMF needs to run Composer in production, they can simply commit the vendor directory in their instance of MediaWiki. For instance, if you were to require the extension like: ``` composer require mediawiki/abuse-filter ``` you would get the abuse filter extension (installed in the `extensions` folder) as well as all of that extensions dependencies installed in the `vendor` directory. WMF could either use a version constraint on the extension, or use `dev#master` which will give them the latest `master` of that extension. This follow's Composer's best-practices and removes the need to manually merge and update dependencies in MediaWiki-Vendor