+1. I've made fresh-composer myself by adapting fresh-node. That won't solve the use case of needing both of them in the same image. Would be nice if there was easier way to specify which image to use.

I've been less concerned about Composer given how few few libraries and virtually all of them by well-known developers, responsibibly updated, and with little to no indirect dependencies. It feels many magnitudes less risky, compared to the npm. But, it's very much in the scope of the project to support this and I too have at times decided to do something ad-hoc for it.

I don't think I can resource this myself entirely, but patches welcome and I'll be happy to guide it through to release and then maintain going forward.

One thing to note is that Fresh generally aims to be a light wrapper and not maintain its own Docker images, so re-using CI images is generally preferred, including because it means you are very likely to be able to reproduce CI failures locally. I'm bringint this up because our CI images for php/composer-test don't contain Node.js, and that means the OOUI usecase will still fail.

Perhaps it would make sense to provide (one) default Node version in our CI images for PHP, and (one) default PHP version in our CI images for Node.js/browsers. That's basically what the custom ooui CI images is today, but maybe that makes sense to just add to the node10-test-browser CI image and reuse that instead of having so many different flavours.

For future readers: The current process for secure execution of composer commands is to use MediaWiki-Docker, which includes an isolated shell environment in which composer is available to use to update packages and run PHPUnit etc, and can run MW maintenance scripts.

Docs: mediawiki-docker.

I've not yet had a situation in which this wasn't easy and sufficient. I'd love to hear from others, especially if they found this not to work for them. Although regardless of that I'd be open to a fresh-php script.

Fresh uses the CI images defined in integration/config such as docker-registry.wikimedia.org/releng/node20-test-browser. Since we have the use case of NodeJS app depending on composer for build/testing, we have child images embedding composer:

They are rebuild anytime their parent images (which are used by Fresh) get rebuild, so they should be more or less up-to-date.

The images are larger though since they have composer, PHP and some PHP extensions. Maybe Fresh can use a feature flag such as --with-php to switch to those child images?

If they are identical otherwise, I think it'd also be fine to use them by default/instead. Sounds good to me either way!

It's only a one-time download after upgrading, right? How much bigger are we talking?