One approach would be to split the deployable vendor repo from the project repo and only combine them on a deployment branch or via Trebuchet as appropriate. The downsides of this are more complex git repo management for the production and possibility of drift between the composer.json in the main project vs the composer.json in the vendor repo, but the upside is easier local development.

Perhaps we can change those repos to not check in vendor/? MediaWiki core and extensions don't do that either.

For the main test job we'd let Jenkins fetch dependencies (dependencies and dev, via composer test), and for the wmf branch (or in case of mediawiki-config etc.) we'd use mediawiki/vendor.

In T92605#1206905, @Krinkle wrote:

Perhaps we can change those repos to not check in vendor/? MediaWiki core and extensions don't do that either.

For the main test job we'd let Jenkins fetch dependencies (dependencies and dev, via composer test), and for the wmf branch (or in case of mediawiki-config etc.) we'd use mediawiki/vendor.

This is basically what I suggested in T92605#1116654. The downside is more complex deployment. For ieg-review and scholarships this can be handled by Trebuchet pretty easily.

For mediawiki-config I'm not exactly sure what we would do. We could use an independent git clone I suppose. It doesn't currently seem likely that we will be adding more libraries to the bootstrapping code for the WMF cluster.

In T92605#1206927, @bd808 wrote:

For mediawiki-config I'm not exactly sure what we would do. We could use an independent git clone I suppose. It doesn't currently seem likely that we will be adding more libraries to the bootstrapping code for the WMF cluster.

Or a submodule? (Like for mediawiki-core wmf branches.) It'd be less error prone and more explicit. A bit more maintenance heavy, too. But as you say, they shouldn't change very often.

Just put dev dependencies in gitignore? One could probably even write a composer plugin that does that automatically, if it is worth the effort.

In T92605#1574097, @Tgr wrote:

Just put dev dependencies in gitignore? One could probably even write a composer plugin that does that automatically, if it is worth the effort.

composer.lock and various files in vendor/composer will change when the installed libs change so a simple gitignore won't quite cover it.

If the dependencies are not pinned to exact versions (which is often the case for projects that version composer.lock) then the composer update && composer update --no-dev dance won't be guaranteed to work properly either as both runs of update could choose to install non-dev dependencies than the ones that are in the versioned composer.lock.

What I have been doing locally for a couple projects with this problem is composer update jakub-onderka/php-parallel-lint phpunit/phpunit ... listing each package in the require-dev section and then after I'm done running tests resetting to the committed state with git checkout -- composer.lock and any other files that were dirtied.

Change 330842 had a related patch set uploaded (by Krinkle):
Add fetch-composer-dev.sh script (derived from mw-fetch-composer-dev.sh)

https://gerrit.wikimedia.org/r/330842

Change 330843 had a related patch set uploaded (by Krinkle):
Add operations-mw-config-composer-jessie job

https://gerrit.wikimedia.org/r/330843

Change 330842 merged by jenkins-bot:
Add fetch-composer-dev.sh script (derived from mw-fetch-composer-dev.sh)

https://gerrit.wikimedia.org/r/330842

Change 330843 merged by jenkins-bot:
Add operations-mw-config-composer-jessie job

https://gerrit.wikimedia.org/r/330843