Jordi Boggiano

Jordi Boggiano Co-Founder of Private Packagist – Dev at TeamupComposer lead – Wandering Belgian – Speaker

Blog RSS Feed Twitter @seldaek


Composer: Installing require-dev by default

Jeremy Kendall started a small twitter shitstorm last night by asking why Composer's install command now installs the require-dev dependencies by default. Indeed until a few months ago the only way to install dev requirements was to run composer commands with the --dev flag. This was changed when the require-dev handling was fixed to be a lot more reliable, and the update command started installing dev requirements by default.

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. The only case where you want them disabled is when deploying to production or other similar environments. Since those deployments should be scripted, adding --no-dev to your script vs having to type --dev every single time you run composer makes sense. I understand it may create some pain in the short run - although having dev requirements installed in prod is usually harmless - but I truly believe it is the right thing to do if you look at the big picture.

Jeremy also said that install is meant for prod, and while this is not a wrong statement per se, I would like to take the chance to clarify that install is not only meant for prod. Install should be used for prod for sure, because you don't want the prod server to run newer packages than those you last tested on your dev machines. But in many cases developers should also run install to just sync up with the current dependencies of the project when pulling in new code, or when switching to an older feature branch or older release to do a hotfix for example. Developers also might need to run install in some larger teams where only a few select devs are responsible to update the dependencies and test that things still work, while the other devs just run install to sync up with those changes.

And for those that are still not committing their composer.lock file, note that the above paragraph only applies if you have a lock file available in the project's git repository. If you are not sure what this file does please read more about it in the docs.

July 11, 2013 // PHP

Post a comment

Subscribe to this RSS Feed Comments

2013-07-11 08:27:22

Hari KT

Thank you for the clarification.

2013-07-11 08:44:27

Dries Vints

Great post. This should be enough to explain the reasoning behind it to everyone :)

2013-07-11 09:23:23

rafael dohms

These are exactly the points I make in my composer talk. Very important that as a team you understand the differences between these.

2013-07-11 09:26:48

Ramon de la Fuente

I think you hit it in the last paragraph;

When it is said "install is meant for prod" it should be re-written to "prod is only allowed to run install". That leaves open alle valid uses for install in other environments you highlighted.

2013-07-11 09:38:50


Thanks for this change. Exactly resolves a very common issue, when introducing composer in teams.

2013-07-11 13:31:21

Dan Horrigan

My problem with this, is for distributing software. You used to be able to tell users "just clone the repo and run composer install." Now you have to add "Ensure you add the --no-dev flag in production" which will just confuse people.

This, in my mind, is like shipping software with debug set to true.

2013-07-11 14:27:11


@Dan: The thing is you can tell them to *always* run "install --no-dev", it will be the same as before. No need to add production specific instructions. But yes it's a bit less simple for that particular case. And yes it requires that you understand a minimum what Composer does before you use it. But Composer isn't a distribution tool, it's a dependency tool for developers, which is why it defaults to development mode. Yet you could use it as a library and build your own tool around it with a super simple interface for the purpose of installing distributed things.

2013-07-11 16:45:11


Thanks, that's really sensible. :)

2013-07-11 17:38:44


I guess a "Symfonic" flag like --env=prod would be more clear for me... This makes more sense if the require-dev or --env=dev mode is the default.

2013-07-11 23:18:57

Mike Willbanks

@Seldaek Dan mentions a point that I actually feel is one of the more valid items. We "can" tell them to run it that way but it feels more uncommon. In the way that I have been using composer since it has come out I felt that this was more or less part of the use case that it was solving.

Yes it is a dependency manager for developers; but if you think about it, it is more or less a package manager for PHP projects - or it has slowly started to grow into that. Overall can we live with the new change; yes. Do I think that the change was short-sighted absolutely. Sometimes changes like these are because you get to close to the project/product with the original intentions instead of how it has started to change organically.

Thanks for all you do on composer!

2013-07-12 17:48:58

Ben Marks

Perhaps we need a composer composer.

2013-07-17 01:18:15

Kevin Bond

Should there even be an update --no-dev? Like you said in your response to Jeremy, that could leave you in a bad situation.