Improve PHP 8.5+ support by avoiding deprecated switch case syntax

[theodorejb]

This must have been a typo, since it's the only instance where the non-standard syntax is used.

[WyriHaximus]

Hey, thanks @theodorejb for taking the time to file this PR. There are two things that bother me with this:

• We have 10+ pairs of eyes on this and none of them spotted this across two PR, how did you find it? Did you ran into some kind of issue?
• Why didn't our tests catch this 😅

[theodorejb]

@WyriHaximus I ran a script across the top Composer packages to find any that were using the alternate switch case syntax, since I'm considering writing an RFC to deprecate it. In the top 1000 packages, this was one of only two where I found it used. All usages appeared to be typos (randomly mixed in with case statements using the standard syntax).

PHP-CS-Fixer will automatically find/fix these issues when using the @PER-CS ruleset (or even the old @PSR2 ruleset).

[WyriHaximus]

@theodorejb Ahh cool thanks, and tbh been doing PHP for 20+ years and only learned today this is valid syntax 🤦 . And honestly that RFC makes sense.

[clue]

@theodorejb TIL! Thanks for looking into this and best of luck with that RFC 👍

(I've marked this as maintenance to emphasize this shouldn't otherwise affect how this code functions.)

[jrfnl]

Could this fix please be released with due haste ?

The PHP 8.5 deprecation has been merged into PHP core and the nightly build for setup-php has been updated (at least the Windows image, the Linux one seems to still lag behind).

This effectively means that the deprecation notice for the code in the 3.2.0 version is currently causing composer installs to fail on PHP 8.5, which means other projects can no longer test against PHP 8.5 to assess their own readiness.

[jrfnl]

For the record, this is the error I'm seeing:

[lolli42]

Yeah. Release would be great due to the "global" composer usage.

We added PHP 8.5 to our CI matrix just yesterday, and decided to greenify our pipeline with a composer-patch: TYPO3/Fluid#1189 (just mentioning in case you need something, too).

[jrfnl]

We added PHP 8.5 to our CI matrix just yesterday, and decided to greenify our pipeline with a composer-patch: TYPO3/Fluid#1189 (just mentioning in case you need something, too).

Just in case anyone desperately needs it - for most CIs, another work-around is to first setup-php with PHP 8.4, run composer install, then switch to PHP 8.5 to run the tests. (yes, setup-php allows you to switch PHP version midway a workflow 😍 )

A new release would be nicer, but ☝🏻 can unblock people if needs be, without needing to patch the package.

[jrfnl]

@WyriHaximus @clue Just a heads-up: the PHP 8.5 Linux nightly image used by setup-php was updated a few hours ago, so you can expect the pressure related to this issue to grow exponentially soonish...
Also, please know, this comment is absolutely not meant as a complaint. I'm just the lighthouse watchperson trying to warn you there's a storm coming.... ❤️

[WyriHaximus]

Also, please know, this comment is absolutely not meant as a complaint. I'm just the lighthouse watchperson trying to warn you there's a storm coming.... ❤️

We know <3, but a few things.

This effectively means that the deprecation notice for the code in the 3.2.0 version is currently causing composer installs to fail on PHP 8.5, which means other projects can no longer test against PHP 8.5 to assess their own readiness.

Unless I misunderstood how composer builds its bins. It takes the lowest targeted version in range. Which is v2 of this package: https://github.com/composer/composer/blob/main/composer.json#L40 and that version still contains this issue:

promise/src/functions.php

Line 369 in 1a84609

case $type instanceof \ReflectionUnionType;

Filed #269 to resolve it in that version as well.

Could this fix please be released with due haste ?

We should.

[jrfnl]

This effectively means that the deprecation notice for the code in the 3.2.0 version is currently causing composer installs to fail on PHP 8.5, which means other projects can no longer test against PHP 8.5 to assess their own readiness.

Unless I misunderstood how composer builds its bins. It takes the lowest targeted version in range. Which is v2 of this package: https://github.com/composer/composer/blob/main/composer.json#L40 and that version still contains this issue:

promise/src/functions.php

Line 369 in 1a84609

case $type instanceof \ReflectionUnionType;

Filed #269 to resolve it in that version as well.

@WyriHaximus Thanks for setting that up!

I've just read through the build scripts from Composer and from what I can see, the PHAR file should be using 3.2.0 at this moment.

How I got to that tentative conclusion:

• The release workflow starts by installing based on the lock file:
  https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/.github/workflows/release.yml#L32-L33
• The composer.lock is currently set to use react/promise v 3.2.0
  https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/composer.lock#L780-L781
• It does re-install again after that, but it doesn't use the --prefer-lowest flag, so I don't see how the react/promise version could change.
  https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/.github/workflows/release.yml#L35-L36
  https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/.github/workflows/release.yml#L12
• And while it does yet another install after that, that install also doesn't use the --prefer-lowest flag:
  https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/bin/compile#L19

This looks to be confirmed when checking the build-script from the last release: https://github.com/composer/composer/actions/runs/16201695550/job/45742084992#step:4:67

The LTS Composer 2.2 branch looks to be on react/promise v 1.3.0, but I don't think the LTS promise is about runtime compatibility with new PHP versions. IIRC, it's only for security fixes.
https://github.com/composer/composer/blob/927b1bfcf8942a3359cd290a91abcf7e6b605332/composer.lock#L573-L574

All in all, my supposition is that the "react/promise": "^2.11 || ^3.2" requirement is more about preventing conflicts for packages which have Composer as a runtime dependency and may use react/promise in their own requirements.
https://github.com/composer/composer/blob/d2a4543db8adc6b3d4b2fb652c953db629328986/composer.json#L40

This looks to be confirmed by the relevant commit and issue composer/composer#12188 which added the ^2.11.

Hope this helps!

[andypost]

Is there any expected date for patch release like 3.2.1?
It would help early adopters like Drupal

[jrfnl]

@andypost You can use the work-around described here to continue testing against PHP 8.5 without this patch.

[andypost]

@jrfnl for Drupal it's just a part of problem so I have to patch vendor

[jrfnl]

Just in case anyone needs some example code for the work-around I mentioned before, I'm applying it as a temporary measure to the PHPCS test workflow (as releasing a new major with red crosses on every workflow run makes me uncomfortable 😉)

Once a new version of Composer has been released, I'll revert it.

[WyriHaximus]

For reference, the relevant RFC: https://wiki.php.net/rfc/deprecations_php_8_5#languagesyntax_deprecations

[clue]

Also, please know, this comment is absolutely not meant as a complaint. I'm just the lighthouse watchperson trying to warn you there's a storm coming.... ❤️

@jrfnl Thanks for the friendly reminder. Discussed this PR earlier today in the team and will prioritize releasing this once the other maintenance PRs on this milestone are merged. Seeing this currently blocks Composer, definitely expect a release this week, hopefully in the next couple of days. If you're impatient, you can always support the project and may help speed things up by becoming a sponsor ❤️

[jrfnl]

@clue Appreciate the update!

[jrfnl]

@clue P.S.: didn't mean to ignore your remark about funding, but I'm not the right audience for that. I'm only a lowly, barely paid open source maintainer myself.

So let me join you in the call for funding:
For anyone who comes across this issue and works for a company making money off open source: please fund ALL your dependencies if you want open source to survive.

[WyriHaximus]

As I just merged #269 and as @clue noted on that PR, the v2 branch will need more changes to get it to work on PHP 8.4. However, as we haven't received any issues about PHP 8.4 compat, and as @jrfnl pointed out in #264 (comment) we're not considering a new v2 tag to address this, unless PHP 8.(4|5) support comes up in an (high profile) issue. Will review #271 tomorrow morning and if it's good merge and release it.

[WyriHaximus]

Bit later than planned today, but v3.3.0 is here

[jrfnl]

Thank you all for getting 3.3.0 released! Now, let's hope Composer updates and releases a new version soon ;-)

[jrfnl]

FYI: I've opened a PR to Composer to update their dependency: composer/composer#12504