Background
Dev tools like PHPUnit, PHPStan and PHPCS are currently in require-dev inside composer.json. This couples the project's dependency graph to tooling versions and can cause conflicts when the SDK is installed in a host project.
Proposal: use Phive
Phive installs tools as standalone PHAR files, isolated from the project's Composer dependencies.
A .phive/phars.xml would look like:
<?xml version="1.0"?>
<phive xmlns="https://phar.io/phive">
<phar name="phpunit" version="^9.5" installed="9.6.34" location="./tools/phpunit" copy="false"/>
<phar name="phpstan" version="^1.10" installed="1.10.0" location="./tools/phpstan" copy="false"/>
<phar name="phpcs" version="^3.7" installed="3.7.2" location="./tools/phpcs" copy="false"/>
</phive>
Then in CI: phive install --trust-gpg-keys ...
Open questions
- Is this change worth the added complexity for contributors unfamiliar with Phive?
- Should we keep a
require-dev fallback for environments without Phive?
- How do we handle GPG key trust in CI?
Background
Dev tools like PHPUnit, PHPStan and PHPCS are currently in
require-devinsidecomposer.json. This couples the project's dependency graph to tooling versions and can cause conflicts when the SDK is installed in a host project.Proposal: use Phive
Phive installs tools as standalone PHAR files, isolated from the project's Composer dependencies.
A
.phive/phars.xmlwould look like:Then in CI:
phive install --trust-gpg-keys ...Open questions
require-devfallback for environments without Phive?