In this post to the bitExpert blog Stephan Hochdörfer shares some updates to his own opinions on the "require-dev gone wrong" problem he previously posted about. In this new post he points out that, while there is an issue here, it's not something that can't be resolved (or has been to some extent).

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.

He points out that, while these two packages help the situation, there's still another "require-dev" issue with tools that don't actually "touch" the code. This requires that a certain version of the tool be run against a certain version of your code, creating a dependency of a different kind. Fortunately there's also a tool to help some with this as well, the php-scoper project that makes it easier to isolate functionality through randomly generated namespaces.

In this latest post to his site Jordi Boggiano talks about the change in Composer a few months back that made it install development resources by default. This was recently argued against by Jeremy Kendall so Jordi wanted to clear the air a bit on the subject.

A couple months ago when releasing alpha7 I took care to note in the changelog that the install command would also start installing dev requirements by default in the next release. I did that change some weeks ago and now people started to notice. The rationale behind the change is fairly simple, it's about consistency and ease of use. Consistency between the various commands which now all default to have require-dev enabled. Ease of use because in 99% of the cases, when you type a composer command by hand you should be doing so on a dev machine where it makes sense to have dev requirements enabled.

He points out that, when deploying to production, it's usually an automated process and adding the "no-dev" flag to the script is pretty simple. He notes that "install" is not only meant for production package management and, while it's used less in development it's not targeted towards one particular environment.

Jordi Boggiano has a new post to his site about a recent update to the Composer tool that can help make managing development-only dependencies a bit easier.

Using require-dev in Composer you can declare the dependencies you need for development/testing. It works in most simple cases, but when the dev dependencies overlap with the regular ones, it can get tricky to handle. In too many cases it also tends to just fail at resolving dependencies with quite strange error messages. Since this was quite unreliable, I set out to rework the whole feature this week-end. The patch has been merged, and it fixes six open issues which is great.

Additionally, to make it easier to work with the development dependencies, they'll by default be installed when you run an "update" in your repository. If you don't want them, you can still use "--no-dev". Also, Composer will manage them in a seperate section from the normal "require" packages. If you're not using Composer to manage your application's dependencies, look over on getcomposer.org for more details.