Issue #4 - Support for PHP 8.2

[Sweetchuck]

Issue #4

[PRGfx]

I'm a bit conflicted here: you using spl_object_id would technically introduce a version constraint to PHP 7.2+ (from what I see). While in general I think that is "safe to assume" by now (also seeing the installation statistics from packagist) and I would be fine with releasing it as a minor version, this "breaks" the dev setup. (I assume it's already majorly broken, but "last time I checked, it worked" ^^) The old PHPUnit version would probably not work with 7.2+ so just changing the PHP versions in the CI configuration would break there at the latest.

As this change is addressing a PHP 8+ problem, I looked into a small upgrade for PHP 8, updating PHPUnit, adding some types, but keeping the interfaces compatible.
I didn't have a better look through your 2.x update yet, but it seemed to make some major changes, so I guess there is not much middle ground to slot in a smaller 8.1+ update.

To have a minor release and keep the stack working, maybe it would be possible to

• add the PHP 7.2 version constraint
• upgrade PHPUnit to version 8
• remove the CI configuration as I don't really feel like debugging that

This feels like a lightweight approach to me. @Sweetchuck does that make sense to you?

[Sweetchuck]

I saw the PHP requirements in .travis-ci.yml, (5.6, 7.0), and the phpunit-5 in composer.json, and I knew that there would be a lot of difficulties to make everything work together. That is why I didn't touch those things.

I forgot to check when was the \spl_object_id() introduced into PHP.
It is a good point no to use it in order to keep the PHP<7.2 compatibility.
I don't like to use the \spl_object_id() either, but I couldn't come up with better idea.
Is there another way to make a unique ID for a package?
For example <name>-<version> or <resolved> or <integrity>?

[Sweetchuck]

Not trivial, but I can write a CI pipeline which runs from PHP 5.6 to 8.3 by using different phpunit versions and refactor the custom test classes, maybe even duplicate them if necessary.
Regarding to the CI, my personal preference is the CircleCI over GitHub Actions.

[PRGfx]

7.2 seems reasonable to me, if it's just changing PHPUnit. For my PHP 8 test all it took was a migration to phpunit.xml provided by the package (and a return-type on a setUp I believe), so that seems fine.
I think with PHP < 8.1 no longer being maintained, we shouldn't waste time on these versions here. I can't imagine that this package is so widely used anyway...

To identify the packages I don't really have a good idea. I was hoping for something like WeakMap, but that became available with PHP 8. So I would suggest just going the 7.2 way.

I can't really judge the CI solutions. Travis and coveralls was a test at the time, but I'm not really attached to it and I didn't use much cloud CI in the last years. In your 2.x branch I see you switched to GH actions. Maybe a minimal 7.2 PHPUnit action is an option?

[PRGfx]

Thank you very much for your work, I really like the cleanup.
I added some questions looking through your changes.

[Sweetchuck]

@PRGfx

Settings / Editor / Inspections / PHP / General

• Dynamic method called as static.
• Static method called as dynamic.

Of course, it could be turned off, but maybe some day it will protect me from a real problem :-)

[hopeseekr]

Not trivial, but I can write a CI pipeline which runs from PHP 5.6 to 8.3 by using different phpunit versions and refactor the custom test classes, maybe even duplicate them if necessary. Regarding to the CI, my personal preference is the CircleCI over GitHub Actions.

I have created this already for my Bettergist Collector project, which while unfortnately is proprietary, I can just gift you the CI/CD script...

The Bettergist Collector downloads, continuously, every single reachable package in Packagist.org, and then runs a whole host of CI/CD + static analysis on them, including phpstan, phpunit (if they have tests), etc., against every version of PHP from 5.6 through 8.3, as supported by each project.

To do this, I utilize my phpexperts/dockerize project. It is the simplist and most complete way to dockerize any and every PHP project, from PHP 5.6 and beyond. I have even written proprietary dockerfiles to support PHP 4.4 for huge multinationals based on that project.

In fact, I can say with full scientific accuracy that I have successfully dockerized 98% of all of the 369,394 packagist projects, with the remaining 2% being bugged in some terrible way (like critical parse errors preventing autoloading).

composer require phpexperts/dockerize
hash -r
PHP_VERSION=8.1 composer install
PHP_VERSION=8.1 phpunit

It uses the latest composer internally inside the docker image.

With all that said, here's the CI/CD system that will test your code against everything:

#!/bin/bash

rm -rf composer.lock vendor
# First, bootstrap with a PHP version known to work.
PHP_VERSION=7.2 composer install

time for PHPV in 5.6 7.2 7.3 7.4 8.0 8.1 8.2; do 
    echo "PHP Version: $PHPV"
    PHP_VERSION=$PHPV composer update
    PHP_VERSION=$PHPV phpunit
done

---

How to support PHPUnit 5-9 and then add support for 10 and 11 is not trivial. A good example of how to do it is at https://github.com/PHPExpertsInc/RESTSpeaker.