Update composer dependencies for Drupal 10.2.0

Also see 📌 symfony/psr-http-message-bridge major version bump Needs review .

https://github.com/guzzle/guzzle/releases/tag/7.8.1
https://github.com/guzzle/promises/releases/tag/2.0.2
https://github.com/guzzle/psr7/releases/tag/2.6.2

Updated MR and #2 📌 Update composer dependencies for Drupal 10.2.0 Active .

Related could be merged here but may leave alone

Added changes from 🐛 phpspec/prophecy v1.17.0 does not support php 8.3 Active to the MR

Seems to be all minor releases. Though with 10.2 out in 3 days wonder if it's too late?

phpspec/prophecy-phpunit 2.1.0 was just released, https://github.com/phpspec/prophecy-phpunit/releases/tag/v2.1.0

Added following changes

Needs review and fixes issues with PHP 8.3 deprecations https://github.com/PHPCSStandards/PHP_CodeSniffer/releases/tag/3.8.0
Composer prevents SF7 https://getcomposer.org/changelog/2.6.6

+---------------------------+---------+---------+
| Dev Changes               | From    | To      |
+---------------------------+---------+---------+
| composer/composer         | 2.6.5   | 2.6.6   |
| instaclick/php-webdriver  | 1.4.16  | 1.4.18  |
| phpspec/prophecy-phpunit  | v2.0.2  | v2.1.0  |
| phpstan/phpstan           | 1.10.47 | 1.10.48 |
| squizlabs/php_codesniffer | 3.7.2   | 3.8.0   |
+---------------------------+---------+---------+

one functional test repeatedly fails

Testing Drupal\Tests\options\FunctionalJavascript\OptionsFieldUITest
    EEEEEEEEE.                                                        10 / 10
    (100%)
    
    Time: 01:38.596, Memory: 4.00 MB
    
    There were 9 errors:
    
    1)
    Drupal\Tests\options\FunctionalJavascript\OptionsFieldUITest::testOptionsAllowedValues
    with data set "List integer: Press button" ('list_integer', array('First',
    'Second', 'Third'), false, 'Press button')
    Undefined array key "attribute"
    
    /builds/issue/drupal-3405696/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:226
    /builds/issue/drupal-3405696/vendor/instaclick/php-webdriver/lib/WebDriver/Container.php:241
    /builds/issue/drupal-3405696/core/modules/options/tests/src/FunctionalJavascript/OptionsFieldUITest.php:400
    /builds/issue/drupal-3405696/core/modules/options/tests/src/FunctionalJavascript/OptionsFieldUITest.php:109
    /builds/issue/drupal-3405696/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
    
    2)
    Drupal\Tests\options\FunctionalJavascript\OptionsFieldUITest::testOptionsAllowedValues
    with data set "List integer: Enter button" ('list_integer', array('First',
    'Second', 'Third'), false, 'Enter button')
    Undefined array key "attribute"

instaclick/php-webdriver 1.4.17 changed attribute(): https://github.com/instaclick/php-webdriver/releases/tag/1.4.17

The relevant code change is https://github.com/instaclick/php-webdriver/compare/1.4.16..1.4.18#diff-...

Previously we were calling it as getAttribute() which has stopped working but switching to attribute() appears to work on both the old and new releases in local testing.

Thank you!
Today mink has releases to append here

If this is targeting 10.2 is there a date this needs to be reviewed by?

I think a bit more packages may add declaration and CI runs for PHP 8.3 in next week, also compatibility with SF7 a bonus

I bet right before 10.2 it should be considered for review

Another interesting question: Why is this NR when there are (a lot of) failing functional tests after the update of behat/mink and friends?

The 10.2.0 release window is 11-15 December, really this needs to be completed towards the start of that window to ensure we have a stable release.

Behat has added more strict typing and the test failures all look related to that. At least two differentissues so far:

1. Radio buttons can only take string inputs, sometimes we pass integers that were previously cast to string; I guess we have to cast this ourselves now.
2. We used to check for the absence of headers by looking for NULL, the argument is now typed to string so it seems this is no longer possible, maybe need to raise an upstream bug for this.

Will continue to investigate.

We can work around both these issues, we should probably issue deprecations and fix the callers properly though.

Opened https://github.com/minkphp/Mink/issues/862 as there appears to be no supported way to check for a non-existent header in Mink, however we do have responseHeaderExists() already which we should convert all cases to use, perhaps in a followup.

We also incorrectly pass headers to drupalGet() in a number of places. The docs say the array should be keyed by header name with the value being the header value; but in some cases we passed numeric arrays with both the header and value concatenated into the array value. This apparently still worked in older versions of Mink but now it is stricter, so I fixed all the cases I could find.

An alternative way around this might be to detect it in drupalGet() and issue a deprecation, maybe we should do that instead?

There are quite a lot of changes here. Unsure if we should just break these out to another issue, and avoid upgrading Mink in 10.2.0.

Not sure what is up with BlockDragTest.

Guessing it is related to the upgrade of the Syn library in the Selenium driver: https://github.com/minkphp/MinkSelenium2Driver/releases/tag/v1.7.0

BC break (when doing custom logic with syn):

    syn JS library was upgraded from v0.0.3 to v0.15.0

Syn is used for drag operations, we have had issues with it before.

This makes me think it might be better to defer this upgrade until 10.3.

+1 to move mink to separate issue it could be upgraded in bugfix release

I created an Issue for Behat 📌 Update Behat from 1.10 to 1.11 Active and reverted those changes from the MR.

Since today is the start of the 10.2 window mentioned #25 took a look at this again.

Tests appear green, applied locally and didn't notice anything weird.

Going to mark but guess it could be left open till the 15th? Or whenever the cutoff is.

Committed/pushed to 11.x and cherry-picked to 10.2.x, thanks!

Do we have an issue already to switch to https://github.com/PHPCSStandards/PHP_CodeSniffer ?

@catch We don't depend on it directly:

$ composer why squizlabs/php_codesniffer
dealerdirect/phpcodesniffer-composer-installer v1.0.0   requires squizlabs/php_codesniffer (^2.0 || ^3.1.0 || ^4.0) 
drupal/coder                                   8.3.22   requires squizlabs/php_codesniffer (^3.7.1)                 
sirbrillig/phpcs-variable-analysis             v2.11.17 requires squizlabs/php_codesniffer (^3.5.6)                 
slevomat/coding-standard                       8.14.1   requires squizlabs/php_codesniffer (^3.7.1)                 

Also as per https://github.com/PHPCSStandards/PHP_CodeSniffer/issues/109 only the GitHub repo is changing now, the namespace on Packagist will stay the same (this has changed since the original announcement).

Oh interesting, I though there was going to be a 301 and we'd eventually want to update, but if it's 100% indirect and also we don't need to change anyway, all good then.

Automatically closed - issue fixed for 2 weeks with no activity.