Discuss whether to enforce the Composer 2.3.5 requirement for more than just core development

Anything less than Composer 2.2 is already EOL, so I think that at a minimum, our runtime requirement should be 2.2.12 (the latest security release on 2.2.x).

But, is there any legitimate reason for Drupal 10 users to be using Composer 2.2 instead of 2.3? As I understand it, the only reason to stay on Composer 2.2 would be for people on PHP versions <7.2, but Drupal 10 itself requires a higher PHP version anyway.

Without a legitimate reason to support Composer 2.2, I think we should add warnings/errors for people using less than 2.3.5 (the latest security release on 2.3.x).

This would be the way to make 2.3 an enforced requirement.

I think we should do this, because Automatic Updates will include a Composer plugin that performs the TUF verification, and that currently requires the 2.2 plugin API. So adding this composer-plugin-api dependency to drupal/core now will mean that we don't add it as a new dependency later, when we add Automatic Updates to core.

If we decide we want to allow Composer 2.2, we can reduce this patch to 2.2. I made it 2.3 for now for consistency with #3215870: Require Composer 2.3.5 for developing Drupal 10 core. Keeping it at 2.3 will mean we can add plugins later in Drupal 10's lifetime (whether for Automatic Updates or others) that use the Composer 2.3 API.

Note that even though Composer 2.3.5 exists, the plugin API hasn't changed since 2.3.0, so 2.3.0 is the latest plugin API that we can require for now. Meaning, #3 would not enforce 2.3.5 specifically, only 2.3.0 or higher. 2.3.5 was a security release, so if we want to also add errors/warnings that an insecure version of Composer is being used if someone is on 2.3.0 - 2.3.4, we'd need to do that separately.

What does the error look like with this set?

Same as other dependency failures. In other words, the following on any Composer operation that checks constraints (which includes composer require and composer update, but not composer install):

Problem 1
    - Root composer.json requires drupal/core 10.0.x-dev -> satisfiable by drupal/core[10.0.x-dev].
    - drupal/core 10.0.x-dev requires composer-plugin-api ^2.3 -> found composer-plugin-api[2.2.0] but it does not match the constraint.

Only tangentially related to this issue, but just wanting to make folks aware of #3293866: Update minimum PHP version requirement for Automatic Updates to 7.4.

    - Root composer.json requires drupal/core 10.0.x-dev -> satisfiable by drupal/core[10.0.x-dev].
    - drupal/core 10.0.x-dev requires composer-plugin-api ^2.3 -> found composer-plugin-api[2.2.0] but it does not match the constraint.

This is very user-unfriendly IMO. For a start there's nothing in there that suggests the way to fix it is to run composer self-update.

I think this might be OK with a custom composer warning, the default error message from #6 is just very unhelpful.

People do use multiple PHP versions for local development with global composer, but tbh I'm struggling to see who would be using both composer + PHP < 7.2 and also composer with Drupal 10.

For example checked when PHP 7.2 support was added to Drupal 7 and it's four years ago #2947772: Fully support PHP 7.2 in Drupal 7, while there are/were Drupal 7 sites around using composer, it was a tiny minority, so you'd both have to be on PHP 7.1 or lower and also using composer on PHP 7.1 or lower for this to affect you. And just having a Drupal 6 install that you're migrating to Drupal 10 would be fine because you wouldn't be using composer with the Drupal 6 site anyway.

Do we have a specific issue in mind where we have implemented similar warning that would happen when installing drupal/core? I tried to do some digging but I could only find examples where we would do that on drupal/drupal or somewhere else. Based on https://getcomposer.org/doc/articles/scripts.md#what-is-a-script-, the event scripts are only getting executed from the root package.

I agree that while the message in #6 is not the most helpful, it is the experience that other projects are providing. Because of that, I was able to find many helpful recommendations from Google by searching with that error message.

So...Automatic Updates is working on an issue to support 2.2.12 or later: #3302524: Support Composer 2.2

The reason it currently requires 2.3.5 is just because we didn't implement checking the running Composer version against Composer-style version constraints.

If we got that issue done, would this issue still be necessary?

Oh, and:

The actual version of the Composer runtime/plugin APIs that Automatic Updates really, truly requires in order to work is...^2.1.

The only reason we try to enforce ^2.2.12 || ^2.3.5 is because versions below that have a known security issue. This is case where we, in our contrib module, bumped up our requirements because we're not as strongly shackled to core's constraints.

Having bundled audit command in https://blog.packagist.com/composer-2-4/ could be also requirement

Discussed this with @alexpott on Slack. We could potentially do this in one of the core provided Composer plugins but it doesn't feel like this would fit the scope of any of the existing plugins. The example about phpunit messaging is not relevant because the messaging was done in run-tests.sh and the phpunit bootstrap.

Based on this, I feel like if we are setting a dependency on specific composer version, we should just use the composer require for that, even if the UX of that is not ideal. I was able to find plenty of helpful articles about addressing that problem from Google. We could also file an upstream issue in Composer for asking them to improve the UX of this use case.

+++ b/composer.lock
@@ -441,10 +441,11 @@
+                "composer-plugin-api": "^2.3",

Note that even though Composer 2.3.5 exists, the plugin API hasn't changed since 2.3.0, so 2.3.0 is the latest plugin API that we can require for now. Meaning, #3 would not enforce 2.3.5 specifically, only 2.3.0 or higher.

I don't know why I didn't see this before, but I just now found https://getcomposer.org/doc/articles/composer-platform-dependencies.md#c..., which means, we could replace the above with:

"composer": ">=2.3.5",

if we wanted to. It wouldn't change the error message in #6 much though: it would just replace "composer-plugin-api" with "composer".

Per the info in that Composer docs page, because the "composer" package is a new feature of 2.2.0, if we went this route, they recommend doing:

"composer": ">=2.3.5",
"composer-plugin-api": ">=2.2.0",

in order to provide a friendlier message for people on Composer <2.2.

Even if we decide not to enforce 2.3.5, then per #3, I think we should at least commit a 2.2 requirement, as in:

"composer-plugin-api": "^2.2",

Should we open a separate issue for that in order to discuss (and commit?) that prior to making a decision on 2.3.5?

#18: makes sense. Just for clarity, if we did:

"composer": ">=2.3.5",
"composer-plugin-api": ">=2.2.0",

Then, the message for people trying to use Composer between 2.2.0 and 2.3.4 (for example, 2.2.18) would be:

Problem 1
    - Root composer.json requires drupal/core 10.0.x-dev -> satisfiable by drupal/core[10.0.x-dev].
    - drupal/core 10.0.x-dev requires composer >=2.3.5 -> found composer[2.2.18] but it does not match the constraint.

And the message for people trying to use Composer <2.2 (for example, 2.1.0) would be:

Problem 1
    - Root composer.json requires drupal/core 10.0.x-dev -> satisfiable by drupal/core[10.0.x-dev].
    - drupal/core 10.0.x-dev requires composer-plugin-api >=2.2.0 -> found composer-plugin-api[2.1.0] but it does not match the constraint.

I agree that the 2nd message is confusing, but how much are we trying to cater to people on Composer <2.2?

Meanwhile, the 1st message (for people who might legitimately be on Composer 2.2 for some reason) is pretty close to understandable. Though per #8, it still doesn't provide info that the solution is to run composer self-update. Perhaps a next step here would be to file a PR in https://github.com/composer/composer to add that message? Though that would neither get done in time for beta nor would help with the old Composer versions that are already released (only with future similar cases).

Its not just even users, but daily new installs(?)

Given #18 and #20, this issue is feeling like a "won't fix" to me, but I'll defer to release managers to decide on that.

Meanwhile, I opened #3313486: Decide when to require Composer runtime ^2.1 (needed by Automatic Updates).

Note that as of this week, Automatic Updates now supports running Composer 2.2 (previously it was requiring 2.3). See #3302524: Support Composer 2.2.

At this point, I think it's safe to close this as a won't fix for Drupal 10. We can revisit with Drupal 11.