require-dev gone wrong!

For a long time, I have been advocating to make use of require-dev to install development tools locally. We use this on a daily basis to install tools like Phing, PHPUnit or phpDocumentor locally for each of our (customer) projects. Given that our focus is on custom projects, this absolutely makes sense. I do not want our projects to use an old version of a given tool or update all our projects constantly to use the latest version of all the tools involved. In addition to that, a simple composer.phar install in the project root should be sufficient to install all dependencies required to build and run the project.

For a long time, this approach had worked fine. Our list of default require-dev dependencies was growing over time, but we did not run into any issues at all. A few weeks back I wanted to upgrade Twig in our PSR-7/ADR micro framework to version 2.0. Unfortunately, this was not possible as phpDocumentor depends on Twig in version 1.0. Sure, I can simply wait until a new version of phpDocumentor gets released, but to be fair, no development dependency should ever dictate version constraints of libraries needed by my application. Of course, this problem only exists when tools do not get updated frequently, then again why should everybody move to Twig 2.0 now?

This problem reminded me of a discussion that was brought up for the deptrac project: One of the authors claimed that deptrac is not a dependency but an application. Back then I disagreed, but given my current experience with a potential dependency conflict, I am beginning to understand the point-of-view. I still want to install development dependencies locally, ideally via composer. However, those kind of dependencies should rather be installed as .phar archives in vendor/bin and thus behave like a "standalone application" and should not "pollute" the application scope or dependency graph. Ideally, those development applications are completely isolated from the main application I am developing.

When I announced the idea of this blog post on twitter a few days back, Matthias Noback jumped in and offered his help. We discussed a few ideas and will share our findings with you soon. In the meanwhile, feel free to leave feedback here.