Remove symfony/polyfill-php74, -php80 and -php81 dependencies

Makes sense to me.

Looking at #3168514: Remove unnecessary polyfills from composer.lock we need to add symfony/polyfill-php80 to the replace-section of the root composer.json to truly get rid of it.

+++ b/composer.json
@@ -41,7 +41,8 @@
+        "symfony/polyfill-php73": "*",
+        "symfony/polyfill-php80": "*"

For completeness should we also add symfony/polyfill-php74 here?

Thought about this, and double-checked again:

"Weirdly" symfony/polyfill-php74 isn't required by any of our dependencies currently (72, 73 and 80 are).

So technically, it's not needed _now_.

Having stressed that last word: Why not be complete, it doesn't hurt now and will prevent symfony/polyfill-php74 hopping on board later on.

PHP 7.4 only added three really obscure functions that I guess nobody is using: https://github.com/symfony/polyfill-php74/blob/main/bootstrap.php

#6 looks great to me, RTBC assuming bot agrees.

Needs a reroll

Retitling and updating IS

I'll get there in the end...

Rerolled

Note to self: More caffeine intake before posting the first patch of the day...

...and the second interdiff of the day...

Besides a (rare, but previously seen-by-me-before) random test failure in Drupal\Tests\book\Functional\BookTest::testGetTableOfContents that wasn't there in the retest, this seems fine now.

Thanks @Spokje. symfony/polyfill-php80 is removed and symfony/polyfill-php74 is also blocked from installing just in case.

Needs another re-roll.

Seemingly TestBot doesn't alert/kicks-back-to-NW issues that fail auto-2-daily-retesting?

Having stressed that last word: Why not be complete, it doesn't hurt now and will prevent symfony/polyfill-php74 hopping on board later on.

If we block unneeded php polyfills from installing, it seems logical to replace symfony/polyfill-php81 as well.

@Eric_A great point! NW to skip symfony/polyfill-php81 as well.

symfony/polyfill-php81 is basically the same story as symfony/polyfill-php74: currently not required by any of our dependencies, but since we're being thorough, let's make sure it doesn't sneak in later.

(I suddenly realize that we've been replacing PHP polyfills in this project for some time but are not in drupal/recommended-project. Seems like an inconsistency... Anyway, out of scope here.)

drupal/core-recommended is build every core release from the a.b.x-dev branches, so we're (should be) good.

(Projects drupal/legacy-project and drupal/recommended-project appear to be maintained manually.
In any case it's not something to worry about here. The perceived inconsistency in replaced packages is a pre-existing thing and can be addressed in its own issue if it is to be addressed.)

#30 looks OK to me.

Committed/pushed to 10.1.x and cherry-picked to 10.0.x, thanks!

I'm tagging this for a release note, even though I sort of doubt this change is disruptive enough to warrant one. These polyfills, by their nature, are not things you should notice the presence or absence of. Nonetheless, erring on the side of caution here.

I don't think this needs one. We are only preventing polyfills from installing where the functionality they add is already provided by the minimum version of PHP that we support. I'd rather not try and explain this in the release notes as I can't see how it would ever affect anyone.

Yep agreed, won't affect anyone whether site owners or contrib. Moving back to fixed an untagging.