Outdated reactphp/promise in bundled composer phar breaks in PHP 8.5 with `Case statements followed by a semicolon (;) are deprecated`

[Synchro]

Description

This is happening in this GH action run.

Run ${GITHUB_ACTION_PATH}/bin/composer_paths.sh \
  ${GITHUB_ACTION_PATH}/bin/composer_paths.sh \
    "" \
    "" \
    "/usr/bin/php" \
    "composer"
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    COMPOSER_PROCESS_TIMEOUT: 0
    COMPOSER_NO_INTERACTION: 1
    COMPOSER_NO_AUDIT: 1
PHP Deprecated:  Case statements followed by a semicolon (;) are deprecated, use a colon (:) instead in phar:///usr/local/bin/composer/vendor/react/promise/src/functions.php on line 300
Deprecated: Case statements followed by a semicolon (;) are deprecated, use a colon (:) instead in phar:///usr/local/bin/composer/vendor/react/promise/src/functions.php on line 300
Composer version 2.8.10 2025-07-10 19:08:33
Deprecated: Case statements followed by a semicolon (;) are deprecated, use a colon (:) instead in phar:///usr/local/bin/composer/vendor/react/promise/src/functions.php on line 300
/home/runner/.cache/composer'
Error: Unable to process file command 'output' successfully.
Error: Invalid format 'Deprecated: Case statements followed by a semicolon (;) are deprecated, use a colon (:) instead in phar:///usr/local/bin/composer/vendor/react/promise/src/functions.php on line 300'

This syntax appears in an outdated version of reactphp/promise which was fixed in that package in November 2024, and released in v3.3.0.

In this output, composer is version 2.8.10, which is current, and it downloads a correct zip version 3.3.0 of the promise package, which does not contain the deprecated syntax. Is there a second copy of composer involved somewhere in this stack? Or is the phar built from different dependencies?

Steps to reproduce

1. Run the composer-install action under PHP 8.5.

[Synchro]

Aha, found it. The composer version in tests/fixtures/composer.phar does indeed contain the old version of the promise package, including the line case $type instanceof \ReflectionUnionType; that's the cause of this issue. I assume a straightforward update of the phar will resolve it.

[ramsey]

That Phar file is in tests/fixtures, so why is it being used in the PHPMailer GH action?

[Synchro]

No idea! As you can see, it's triggered from /bin/composer_paths.sh, which is run by the action. I'd be suspicious of the plain composer (without a full path) in that command; I guess it might be picking it up from some odd location that happens to be in the $PATH? Unless there's some other phar around that happens to contain the same problem?

[jrfnl]

I suspect the problem is unrelated to the composer.phar used in the tests here.
The issue with the react/promise package was a known issue and has only been fixed with the release of Composer 2.8.11 (which was released one hour after this issue was opened), so if Composer 2.8.10 was used in the test run (which actually uses Promise 3.2.0), that explains everything.

[Synchro]

The action is indeed working now (even though I couldn't see the issue in composer 2.8.10), but I assume that means this action needs an update for its bundled version anyway if the tests are going to work in 8.5?

[jrfnl]

The action is indeed working now (even though I couldn't see the issue in composer 2.8.10)

@Synchro Could you explain what you did to not see the issue in Composer 2.8.10 ?

Just in case anyone is wondering:

• Composer 2.8.10 was "locked" at Promise 3.2.0.
• The issue in reactphp/promise was fixed in November last year, but was never released until three days ago (Promise v3.3.0)
• The version used by Composer was updated for the 2.8 (and main) branch the next day.
• It was then released via Composer 2.8.11 the day after.

... but I assume that means this action needs an update for its bundled version anyway if the tests are going to work in 8.5?

Probably, but this only becomes an issue once PHP 8.5 gets released.

All tests run with PHP latest as the tests for this package are not testing anything PHP, but are testing the shell scripts.
The version of Composer used in most tests is handled by setup-php, so not the responsibility of the tests for this package.
The functioning of Composer itself is also not the responsibility of this package, but should be safeguarded by Composer itself.

IIRC the composer.phar test fixture is only used for one (or maybe a few) tests which test the handling of pointing to a specific composer.phar file.

[Synchro]

I misinterpreted the state of things. I saw that the composer release was 2.8.10, and looked at the bundled promise and found that the semicolon problem wasn't there, so I assumed it was fixed, but I didn't notice that that change had not been tagged for release.