Travis: require PHPUnit 9.3 for PHP 8 #175
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PHPUnit 9.3 is not yet released (expected end of August), but is slated to add official PHP 8 support to PHPUnit.
As some tests are failing due to the new reserved keyword
match
being used in PHPUnit, I'm (temporarily) upping the PHPUnit requirement for PHP 8 explicitly to PHPUnit 9.3 (dev).Once PHPUnit 9.3 has been released, this condition can be removed in favour of changing the requirements in the
composer.json
file.Note: for now the
--ignore-platform-reqs
is still needed as the underlying dependencies may still not have tagged a version which officially supports PHP 8 and this would cause a requirement conflict.Ref: sebastianbergmann/phpunit#4373
Note: I've investigated the other unit test failures on PHP 8 and have confirmed that all of them will be fixed once PR squizlabs/PHP_CodeSniffer#3027 has been merged.
I don't think any special accommodation is needed in PHPCSUtils for this for when people run an older PHPCS version on PHP 8, as from the looks of it, the functions work just fine, it's just that the exact expected token pointers and such will be different than the expectations set in the unit tests. They are correct though.
The only time when the output is significantly different is for
getTokensAsString()
and its variants, but that is to be expected.