Require mikey179/vfsstream ^1.6.11 to allow tests running on PHP 8.2

Opened #3299662: [upstream] Ensure 10.0.0 is on stable versions of dependencies before release.

Can probably be needs review?

RTBC for 10.0.x and 10.1.x, will need a separate patch if we are to do this in 9.5.x as well.

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

Even though we might not get to 100% PHP 8.2 support in 9.5.x, it's worth backporting the dependency update in its own right, so moving there.

I think you mean "...and cherry-picked to 10.0.x.".

YAY!

Just a patch update for 9.5.x which is good.

Committed/pushed to 9.5.x, thanks!

+++ b/composer.json
@@ -21,7 +21,7 @@
-        "mikey179/vfsstream": "^1.6.8",
+        "mikey179/vfsstream": "^1.6.11",

How come we're updating the constraint here? We're still compatible with 1.6.8 - upping how constraints all the time makes us less compatible - I think we should only update these when we move to a new minor / there is a security release. I don't think it matters so much with dev dependencies but it's the precedent that it sets that is worrying to me. If you want dependencies locked to what Drupal is using on DrupalCI then we already have a composer meta package for you.

It is tricky because it depends on PHP version. PHP 8.1 is fine with 1.6.8, but for PHP 8.2 we need 1.6.11. In an ideal world mikey179/vfsstream would not declare compatibility with PHP versions until they are released, but in practice this does not happen; it has always simply required php >=5.3.0. Should we be declaring the lowest that works with any version or the lowest that works with all versions?

It would be good if package owners could mark old versions as incompatible on Packagist, so mikey179 could retrospectively flag 1.6.10 and earlier as incompatible with PHP 8.2 even though it wasn't declared when those versions were released, and Composer would later respect that - but in practice I'm sure this would have a ton of side effects that mean this isn't feasible.

In an ideal world mikey179/vfsstream would not declare compatibility with PHP versions until they are released

This also isn't an ideal world - we've had packages that were compatible in practice, but didn't add the version or tag a release, so we couldn't update them.

Should we be declaring the lowest that works with any version or the lowest that works with all versions?

The lowest that works with any version. In most cases it should be composer's job to work this out. Adding further restrictions makes it harder for everyone. The robustness principle applies here. We should be as liberal as we can be and work in the widest range of situations without getting in people's way - whilst using our lock file to be as strict as we can be on what we use. We go one step further because if you want to limit yourself to using the exact versions Drupal uses we supply a composer project to do just that.

The lowest that works with any version. In most cases it should be composer's job to work this out.

We can't have it both ways:

- if a dependency declares an upper bound for PHP version compatibility, then composer will show an incompatibility if you try to install it on PHP 8.2 - but we end up in a laminas situation (#3180207: Update laminas-diactoros, laminas-escaper and laminas-feed for PHP 8 compatibility) which is a complete pain for Drupal PHP compatibility overall.

- if a dependency doesn't declare an upper-bound, then composer will happily continue to install the older version on PHP 8.2, so we either decide that's fine and people can update it when they get an error, or we should increase the constraint to one that works with all supported PHP versions.