In this post, I would like to give a quick summary of the PHIVE tool, what it allows to do, and invite you all to trial and discuss this. Maybe it will be useful for you to adopt.
Manage Local PHP Tooling
The idea behind PHIVE is to provide an optimized and streamlined way for managing all PHP tooling that is required to build software, including dependency management, quality managment and more.
PHIVE manages all phar files for tools like PHPUnit, PHP_CodeSniffer, and also Composer or even WP-CLI in a central place—in your user directory. Each project will then symlink the required tools, in the desired versions. These are stored in the tools folder in your project, so you would have, for example, tools/phpcs for PHP_CodeSniffer. This means that you will only ever have one instance of, say, PHPUnit 7.5.0 installed locally, but you might have several projects referencing it. And, of course, you can have several other versions of PHPUnit installed, too, for other projects to use.
If you want, you can also actually copy the tool right into your local project folder, though. Maybe you want to play around with hacking some files, or whatever the reason might be. It is possible, if you need that.
Similar to the composer.json file, PHIVE has a custom config file, by default located in .phive/phars.xml. The path and file name can be customized, though, and several projects make use of a phive.xml file in the root. This file contains the version constraint specified when installing a dependency, as well as the exact version that has been installed when the config file was created. The config file would usually be included in Git, so everyone is using the same tools in the same versions.
That way, you can easily have Composer v1 for these projects, and Composer v2 for others, without having to do something or even think about it.
PHPUnit and PHP_CodeSniffer might be the most relevant tools that can be managed with PHIVE, but there might be projects that use phpDocumentor, or WP-CLI, or PHPStan, or Psalm, or more. All of these are supported out of the box, and it’s also possible to pull in custom .phar files from any location, if need be.
Advantages Over Composer
Maybe you are wondering why this is better than using Composer to manage the tools, right?
It’s true that Composer can be used to do this, and, in fact, we are doing this for most of the projects. However, all Composer dependencies affect each other, and the platform. There are several downsides of that. Let’s assume that your project code should be built for PHP 7.4. And let’s assume you want (or maybe need) to run your tools in the most recent version, which maybe only supports PHP 8. There is a Composer issue for that, which was closed a long time ago, but still people come back to it, because it is frustrating.
Or let’s assume your production code has a dependency on, say, Symfony Command. Just like PHPUnit, or other developer tooling. Now, let’s assume the two version constraints are incompatible with one another. This should not prevent you from using the tools in whatever your desired or required version is. The dependencies needed to build your software should not affect, or be affected, by the dependencies of your developer tooling.
Also, if you already have the tools installed on your machine, and if they are no longer part of your Composer dependency tree, living in the vendor folder, everything will be (at least a bit) quicker, and smaller.
Potential Issues
There are a few things that you would need to change in your workflow, or in scripts and aliases, maybe. And there might also be issues you will run into, given that tools, which are currently managed via Composer and thus stored in vendor, are now represented as symlinks in tools, referencing binaries in your user directory. However, most of these issues would be the same as when you are using a globally installed PHPUnit.
I suggest to collect issues we run into, and see where and how they might get addressed. For example, there is already a PR on the PHP_CodeSniffer repository making the CodeSniffer.conf file path customizable. This is useful for projects that use the phpcodesniffer-composer-installer Composer plugin.
Thoughts?
I’d love to hear anyone’s thoughts on this, as well as reports in case you trialed PHIVE, now or some time ago.
Leave a Reply