(Partially) solving the require-dev problem

This blog post has been sitting on my desk for quite a while but due to a lot of work in the last weeks I was not able to finish it earlier. Luckily, I found some time during my travels to finish the blog post and share my findings on the "require-dev gone wrong!" problem. While some people thought the former blog post was mostly click bait or proposed a "fix" which does not actually solve the general problem, I actually got a lot of good feedback on twitter. Even an issue for Composer was created to discuss the problem even though it was closed by now.

The gist of all this is that, yes, we do have a problem. Fortunately, there are already solutions out there - none of them perfect, but there's always room for improvement isn't there? Installing .phars with Composer is currently not supported out-of-the-box by Composer but there are 2 projects to help us deal with it: One is tooly-composer-script - a Composer plugin that manages to pull .phar files from a remote location. The other one is PHIVE - the PHAR Installation and Verification Environment. PHIVE goes a bit further by also providing support for verifying the SHA1 and GPG signatures as well as making the archives executable. The "downside" of PHIVE is that you need to use an additional tool to install those dependencies. Luckily this will change in the near future - or at least will be made easier - as Tommy Mühle, the author of tooly-composer-script is currently working on a Composer plugin for PHIVE which will combine the best of worlds - installing .phar during a "composer install" run.

However, this does not solve all of our problems. In the twitter discussion it became clear that we deal with 2 kinds of require-dev dependencies: The ones that work "on-top" of your code or don't touch your code at all, tools like Phing, phpDocumentor or Codesniffer. On the other hand, we have to deal with tools that closely "interact" with your code, tools like PHPUnit. The tools that work "on-top" of your code can easily be replaced by their .phar versions and you will not notice any difference. The "problem" are tools like PHPUnit which interact closely which your code, like loading your classes and their respective dependencies during a unit test run. In that case, we still have a problem: When the tool shares a dependency with your code, the dependency is already loaded once the tool starts up and thus your code will be run (or tested) against that specific version of the library that comes with the tool. Good for us that there is a solution for that problem as well. Webmozart created the php-scoper project a while ago. A project that allows you to prefix all PHP namespaces in a file/directory. If you add this tool to your phar build chain you would end up with completely random namespaces for your tools and thus avoid any conflicts. A "creative" work-a-round for the problem of colliding namespaces.

In the twitter discussion it was mentioned that the phpDocumentor team will not support composer installs in v3 any more because of that exact issue.