GrumPHP v0.14.x isn't compatible with Composer2.x #239
Conversation
leith
force-pushed
the
travis-grumphp-composer-compatibility
branch
from
6e49ba6 to
88cae25
Compare
|
PHP 7.3 failure is due to bug in Travis with the latest version of Xdebug. I'm hopeful that it's temporary, but this at least addresses the intended problem (GrumPHP/Composer compatibility). |
|
I think Travis is dead soon anyways, probably need to move to GitHub actions. And grumphp could be removed before the tests. |
|
@barryvdh not sure I can make a PR for adding actions (that will actually work, anyway, since I'm not a member), but can modify this PR in the mean time to remove GrumPHP dynamically from travis build if that's the preferred approach? |
|
Just revert Composer to v1 👉 #241
Travis CI is a mature product, they just started focusing on paying customers. |
That's exactly what this branch did in the first commit. 😅 |
|
Fixed with #247 |
The CI tests are failing because the required version of GrumPHP is incompatible with Composer Plugin API v2 - support was added in v0.18.1, however by that point they had also dropped support for PHP 5.6, 7.0 and 7.1, which means our CI tests in those environments will always fail due to incompatible dependencies.
The alternative would be to fork GrumPHP v0.14.x and add Composer v2 support, open a PR and hope it isn't closed. Considering they are many versions past this an unlikely to care about PHP 5.6 at this point, that seems a bit unlikely?
Reverting Composer to 1.x for Travis seems like the fastest way around this, although this should be removed when Omnipay drops support for older versions of PHP and can update the dev-requirements to a newer version of GrumPHP.