Add a command to show updates excluded by current constraints.

[realityking]

Once you get to a significant amount of dependencies it gets hard to track releases for everything. I'd like to see a command to list all packages for which there is a newer version than allowed for the current constraints.

For example, one of my composer.json contains the following requirement:

"jeremykendall/php-domain-parser": "0.0.*",

Now by pure chance I discovered that a few weeks ago version 1.0.0 and 1.1.0 have been released.

[MattDunbar]

I'll take an attempt at this today. Its my first contribution to Composer / first time working with the source, so no promises.

[Seldaek]

This is kinda covered by #2404 as far as I understand.

[MattDunbar]

Would supporting a wildcard * in place of the package name on #2404 be helpful / acceptable?

[MattDunbar]

Nevermind - just re-read this. I'll find something else to work on here.

[Seldaek]

@MattDunbar alright cool, just watch out for open pull requests. There are quite a few that are awaiting merging because I've been quite backed up at work.

[sun]

This was once proposed in #210 already — x-posting from there, since that's a closed PR (~=nirvana):

The equivalent npm outdated command produces a nice tabular report; e.g.:

$ npm outdated
Package                 Current  Wanted  Latest  Location
grunt-contrib-concat      0.4.0   0.4.0   0.5.0  grunt-contrib-concat
grunt-contrib-compress    0.9.1   0.9.1  0.10.0  grunt-contrib-compress
load-grunt-tasks          0.4.0   0.4.0   0.6.0  load-grunt-tasks
shelljs                   0.1.4   0.1.4   0.3.0  grunt-release > shelljs
semver                   2.0.11  2.0.11   3.0.1  grunt-release > semver
...

Contrary to composer update --dry-run, it additionally shows the latest available release for each package beyond composer.json version constraints.

Additionally, not visible in the above copy, packages are differently colored depending how severely outdated they are; i.e., red if Current/.lock < Wanted/.json, yellow if Wanted/.json < Latest, etc.

That's very useful when your project has many dependencies. But also for debugging + communication purposes (e.g., to compare environments).

---

#2404 suggests to bake this info into status, but that's a bad idea, since status is about local changes, not checking for updates.

An outdated command would also help to resolve issues like #1563 - i.e., to determine why update doesn't update to the latest available release.

ref: sebastianbergmann/phpunit#1066

[Seldaek]

Closing as duplicate of #1563, will be fixed by #5028 I believe.