**Problem**
I tried adding a new dependcy to an extension with composer's CLI:
```
composer require wikimedia/equivset
```
This all works perfectly locally and all the tests pass. I then commited the changes, but the tests failed.
I was instructed by another developer that I needed to update #mediawiki-vendor in order for the tests to succeed and the dependency to be available on the WMF cluster.
This seems like a completely unnecessary unique practice. On top of this, the deps in #mediawiki-vendor must be manually maintained.
**Solution**
Instead of maintaining a repo of dependencies. WMF ought to 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`.
This follow's Composer's best-practices and removes the need to manually merge and update dependencies in MediaWiki-Vendor