Update ProcessOutputCallback to fail on Composer deprecations, to get early notifications of Composer changes

Blocked on 📌 Allow JsonProcessOutputCallback and other Composer runner callbacks to gracefully handle deprecated command options Fixed .

Needs proposed solution

Maybe since ProcessOutputCallback::getOutput is logging warnings using

$this->logger->warning($error_output);

we can use the count for warnings to be sure that there aren't any new deprecations.

Discussed with @omkar.podey earlier today.

LGTM! 👍😄 Thanks!

Wim Leers → credited phenaproxima → .

Why has this not been committed in >1 month time? 😬😳

Why not indeed!

A few very small things, but otherwise this looks good.

Decided to make the test coverage a tad more thorough; assigning to @tedbow for final review.

Another way to solve this problem would be to ask composer( and maybe provide a PR) to add a --no-deprectations flag. Basically have composer fail if any deprecations are used. I am not sure how else you could write tests that rely on composer commands and be alerted to deprecations

Hey everyone. Thanks for all the work on this!

But I think we need to rethink why we need this issue at all.

Presumably we need this issue because we don't want to be surprised when Composer 3 out comes and have our code break because we are using deprecated options or commands that will throw exceptions in Composer 3. The other reason would be to be helpful to other developers that might be using the Package Manager API and using options or commands that we don't use and that also might be deprecated.

The best way to solve this would be to use a matrix of composer versions in our tests. Right now there 2 problems with this.

1. There are no Composer 3 releases we could test against https://github.com/composer/composer/releases
2. Drupalci doesn't give us the ability to use matrices
3. We don't want to switch to Gitlab Actions now because although it is available to use on all contrib projects Drupal core does not use it and any changes we made to our testing we would have to remove when we tried to get into core

Because there are not any Composer 3 pre-releases and \Drupal\package_manager\ComposerInspector::SUPPORTED_VERSION restricts Package Manager from using Composer 3 even it is was available there is zero chance right now anyone would be using Package Manager with Composer 3 and it will probably be a while.

Since we are blocked on getting into Drupal core because of needed changes to Drupal.org infrastructure and related security reviews it is likely that by the time we get into Drupal core it will already be using gitlab actions and then we would be free to use it ourselves to run our tests on a matrix of Composer versions. We would probably want to do that anyways to avoid problem unrelated to declared deprecations such as we found in 🐛 As of Composer 2.5.5, `composer config` JSON-encodes boolean values Fixed

Even if core is not using Gitlab actions by the time we get into core we will still be an experimental module so I think it would be fine not to have warnings for Composer deprecations at that point.

I am postponing this issue for now and we can reopen when we get closer to getting into core if are not able to switch to Gitlab actions at that point