Increase Composer dependency constraints to latest minors for forward-compatibility

I have been inspecting the commit history of composer/Metapackage/CoreRecommended/composer.json but cannot find any prior example like this. So … after spending a good while reading and diffing and googling, I still don't know what the concrete increases would/could be.

The updates cited have already been committed to 9.4.x. So … forward compatibility in/with what? Of 9.3.x with 9.4.x? 9.4.x with 10.0.x?

The closest examples I found are #3199199: [meta] Add compatibility for the latest major and minor versions of dependencies to Drupal 9 and #3267879: [meta] Add compatibility for the latest major and minor versions of dependencies to Drupal 10, but neither of those seem to cover what @xjm wrote in that comment.

👍 Thanks for that clarification! 🙏

I think that forward mitigation is then the prudent and least disruptive choice we can make.

It’s in line with what can be expected of a Drupal core minor release. And helps make Drupal core security releases also be in line with expectations.

I inspected everything in core/composer.json's require and compared to what's in composer/Metapackage/CoreRecommended/composer.json. Whenever the latter requires a newer patch version, I didn't make any changes. Whenever the latter requires a new minor version, I did update core/composer.json accordingly. (No major version differences exist — that's impossible.)

But then there are at least some things to pay extra attention to:

1. twig/twig: core/composer.json was explicitly updated to use Twig 2.14.11 in #3262583: Twig 2.14.11 update, but with zero context provided in that issue. 😬🤔 And #3278162: Update Composer dependencies to the latest minor and patch versions then updated only composer/Metapackage/CoreRecommended/composer.json to Twig 2.14.13. After some digging, that was AFAICT because of https://www.symfony-news.com/news/details/twig-security-release-disallow..., which resulted in https://www.drupal.org/project/drupal/releases/9.3.5.
2. doctrine/reflection was still at ^1.1 in core/composer.json but has been at 1.2.2 in composer/Metapackage/CoreRecommended/composer.json since October 2020. For consistency sake, I updated core/composer.json to ^1.2.
3. doctrine/annotations: similar thing: a minor increment, but the recommended version was specified in August 2021.
4. … and apparently also similar story for symfony-cmf/routing, egulias/email-validator, masterminds/html5, symfony/psr-http-message-bridge, asm89/stack-cors and psr/log.

End result: every require dependency in core/composer.json gets updated with the exception of:

• PHP version + extensions
• All Symfony packages (except symfony/psr-http-message-bridge)
• typo3/phar-stream-wrapper
• twig/twig
• guzzlehttp/guzzle
• stack/builder
• pear/archive_tar

… which remain unchanged.

Thanks for the reroll, @quietone!

Queued a test for #12 too.

Well that's interesting:

Testing Drupal\Tests\ComposerIntegrationTest
F........S.....S..............................................    62 / 62 (100%)

Time: 00:00.094, Memory: 6.00 MB

There was 1 failure:

1) Drupal\Tests\ComposerIntegrationTest::testComposerLockHash
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'c19318bd4afee3527153bbbbfc0e1ca89e127fc0'
+'78bbfc3df240b4eda4a4862733490c55dacbf5d1'

Fortunately there's this:

  /**
   * Tests composer.lock content-hash.
   *
   * If you have made a change to composer.json, you may need to reconstruct
   * composer.lock. Follow the link below for further instructions.
   *
   * @see https://www.drupal.org/about/core/policies/core-dependencies-policies/managing-composer-updates-for-drupal-core
   */
  public function testComposerLockHash() {

… unfortunately it does not mention content-hash at all. It only mentions "hash" once. And composer update --lock does not actually update the content-hash for me.

Those docs were added in #3192842: Make our README more welcoming by converting it into an "entrypoint" into the Drupal ecosystem. I tried pretty much all the composer commands listed there. (Twice: once with 2.1.9, once on the latest: 2.4-dev+556450b15b6c47c55ffa46bd9048b410d56c3983).

My composer-fu is not strong enough for this one 😬 I really wonder what I'm doing wrong 🙈 Really curious about this one!

I can actually reproduce this failure locally. A single change in core/composer.json will cause a different content-hash.

But … it fails on both 10.0.x and 9.5.x. Why does it on d.o only fail on one of the two branches?! 🤯

Looking at the commit history, there's a lot of times where the hash (well, one of the two hashes that get checked — the test method is named pretty confusingly) got out of sync, and caused problems only on some environments. I'll accept that I do not fully grok composer.

As far as I can tell, we need more changes in both patches. Trying that here. 🤞

Both of these are with the patches above applied, then composer update --lock to generate an interdiff, the combination of the two makes for the patch.