Relying on A Dev-Master Dependency in Composer

I recently tweeted this:

I got a few responses asking me to expand so I thought I would take the opportunity to write more than 140 characters on this topic.

When adding a dependency to my system, I will always try to pick one that is installable via Composer (these days, basically every project can be installed this way). However if you see in the installation instructions that you should use version "dev-master" – that means that you’ll always install whatever is currently on the tip of the master branch in this project. There’s a vanishingly small number of situations where I’d want to do that. They are:

  • This code is internal to an organisation, and is common to more than one project but not used by any external people so it is possible to track this dependency
  • I’m depending on my own fork of something for a good reason (and even then it would not be the master branch, but it would be the tip of a potentially evolving branch rather than a reliable release so it’s still kind of the same)
  • The package is special in some way and *should* release as many updates to me as humanly possible, such as

Outside of these possibilities, if your project doesn’t have a named release I can only assume that either it is so alpha that I probably don’t want it in my project anyway* or that you don’t actually know how to tag a release for packagist (in which case, I doubt your wider technical abilities, sorry).

In summary: check your composer.json files for "dev-master" entries and replace them with an appropriate expression which includes your current version (see This means that you won’t get unexpected updates that might be breaking changes, but you can safely upgrade within your specified versions. To find out what version you currently have, look for the package in your composer.lock file as it will say what’s currently installed .

* another exceptional circumstance is where I expect to contribute to or at least follow closely the development of a very new tool, in which case I’ll accept the risks involved!

11 thoughts on “Relying on A Dev-Master Dependency in Composer

  1. Use “composer show -i” for a nicer view of the currently installed versions better than look in the composer.lock.

  2. Or to get a required hotfix before it gets tagged to a release. Which at that point you have to remember to change it back.

  3. Pingback: Using Composer with shared hosting | Rob Allen's DevNotes

    • The mechanics work, certainly. My point is more about choosing the packages to include in your project and how a project’s lack of packaging might influence that

  4. Pingback: PHP Annotated Monthly – January 2016 | PhpStorm Blog

Leave a Reply

Please use [code] and [/code] around any source code you wish to share.

This site uses Akismet to reduce spam. Learn how your comment data is processed.