Validate compliance with composer minimum stability during PreRequireEvent

Discussed with @phenaproxima, @yash.rode, @tedbow — outcomes:

1. Implement a PreRequireEvent subscriber, which validates this (by comparing the version constraint with the root-level minimum-stability and provides a nice message, unlike what composer would generate (and specifically detect the presence of an @stability-flag part in the version constraint and never complains when that is present)
2. Need follow-up for project_browser, because after this issue lands, that validator will prevent the user's choices made in Project Browser to actually result in a module getting installed, if that module is e.g. only available in beta, and the user wants this module, Project Browser should prompt the user to explicitly ask the user that they understand the risks of installing a non-stable module. If the user confirms/acknowledges, Project Browser should specify not drupal/modulename 1.0.0-beta1 but 1.0.0-beta1@beta — i.e. it should specify a stability flag.

On the right track! Looking elegant already, but would like to see more thorough test coverage 😊

I have one question on the MR so assigning it to you.

Answered your question, and also did a new round of review — I have follow-up remarks to both of my previous remarks you addressed 🤓

Tried addressing the addition to the validator!

I have a small doubt on the MR

Discussed that small doubt in a meeting earlier today. That is addressed now 👍

But … there are still quite a few small oversights in this merge request, plus a major problem in a test, plus a critical bug. So not quite there yet. Fortunately, none of these bugs are particularly difficult to solve 😊

Please do a thorough self-review of every line before asking for a review next time.

I really wanted to RTBC this (and already deferred one subjective thing to @tedbow) but … in his review of my merge request at 📌 Limit trusted Composer plugins to a known list, allow user to add more Fixed , @tedbow asked to stop using

$active_composer = $event->getStage()->getActiveComposer();
$active_composer->getComposer()->THINGS();

… because that is using composer/composer.

Since 📌 ComposerSettingsValidator should run `composer config` to determine if HTTPS is enabled Fixed , we should use ComposerInspector. I just tried it locally, and that should be possible here too. So … back to .

I need some help:
Just checking if(str_contains($key, 'extra'))in \Drupal\package_manager\ComposerInspector::getConfig is not enough the test fails. So I added a third parameter to getConfig to differentiate between jsonCallback and new callback we added, I am not sure about this approach?

Mind = blown by the stupidly terrible documentation for composer config, which caused @yash.rode to get stuck multiple times, my suggested work-around to be wrong, the code that @tedbow and I to be fooled in 📌 ComposerSettingsValidator should run `composer config` to determine if HTTPS is enabled Fixed too: the --json flag exists ONLY for

1. extra.* key-value pairs, and
2. for decoding the given string into JSON when setting the value

So it’s supposed to only be used when setting values, not when getting them 🤯🙃 Observe this by trying composer config extra.property true vs composer config extra.property true --json… and that composer config allow-plugins also returns JSON!

Fix pushed in https://git.drupalcode.org/project/automatic_updates/-/merge_requests/68....

Whew this is one hell of a beast of an issue suddenly. Not only challenges with ComposerInspector, but also with composer/composer itself!

After a detailed discussion with @tedbow and @TravisCarden (crediting both), created this upstream issue: https://github.com/composer/composer/issues/11302.

Also addressed all of my own feedback, because this IMHO should land ASAP — it implements exactly what we discussed during scrum, and helps other issues not having to deal with the same stuff that @yash.rode was forced to fight!

Wim Leers → credited TravisCarden → .

Tests failing will take a look

🎉

Thanks for teaching @yash.rode and I about Semver::satisfies()!

Automatically closed - issue fixed for 2 weeks with no activity.