Proposal: adding a composer outdated command

[jenssegers]

Hey guys,

When I'm using other package managers, I often use commands like bower list or npm outdated to find out if packages have a newer release, and can be upgraded. However, composer is kind of lacking this functionality. There is the possibility to run the update with the --dry-run option, but that will not tell you if there is a newer version if you have strict versions in composer.json.

Is this something that could be on the roadmap?

[hannesvdvreken]

@jenssegers What does npm outdated do exactly? Will it check if the max version constraint of your dependencies is lower than the newest stable or dev version of that package? Or does it check recursive dependencies as well?

[jenssegers]

I think npm outdated shows both the max version based on version constraints (similar to --dry-run) and the lastest version of the package in general.

[dantman]

Package             Current    Wanted  Latest  Location
lodash                3.3.0     3.3.1   3.3.1  lodash
ms                    0.6.2     0.6.2   0.7.0  debug > ms
chalk                 0.4.0     0.4.0   1.0.0  nomnom > chalk
...

Yes, it shows the current version, highest matching version according to constraints, the latest version you can update to, and it does it for the dependencies of your dependencies too.

[danez]

I also would like to see something like this. I thought about starting a pull request, but this gets kinda complex, at least with no knowledge in composer internals.

[nervo]

👍

[ojhaujjwal]

+1

[watilde]

+1

[Addvilz]

+95

[davidspiess]

i miss this feature a lot!

[hannesvdvreken]

You can actually do composer update --dry-run and watch the output. It gives you a list of all packages (sub dependencies as well) which could be updated. All you gotta do is filter out your first-line dependencies.

[Addvilz]

@hannesvdvreken --dry-run does not give information about packages, versions of which are locked at some version. For example, if package has version 2.5.0 and composer.json has ~2.4.4, we will not receive 2.5.0 update. That is what this proposal is about.

[dnagirl]

yes please!

[OzzyCzech]

+1

[nevvermind]

This could be easily implemented as a plugin if this was in place: #3377

[fedeisas]

+1

[vinkla]

+1 This would definitely be a great feature. npm-check-updates does this very well for node packages.

$ npm-check-updates

 express           4.12.x  →   4.13.x
 multer            ^0.1.8  →   ^1.0.1
 react-bootstrap  ^0.22.6  →  ^0.24.0
 react-a11y        ^0.1.1  →   ^0.2.6
 webpack          ~1.9.10  →  ~1.10.5

Run with -u to upgrade your package.json

Maybe we could have a similar setup showing installed and the latest available version?

[ezzatron]

+1

[joshuaspence]

+1

[shadowhand]

+1

[dolfelt]

+1

[ameech]

+1

[mvanhorne]

+1

[vinkla]

In the meantime we can use this package: https://github.com/vinkla/climb It is still in early stages of development but it is a start.

[tobiastom]

+1

[kriswallsmith]

👍

[tpetry]

+1

[alfaproject]

+1

[tamtamchik]

+1

[mmoll]

👍

[hannesvdvreken]

If @vinkla, or one of composer's contributors (or someone else) wants to integrate that into composer and maintain that: great.

Just sayin' we can stop +1-ing this thread as we can move on with our lives using this tool 😉

[mtangoo]

Any plan? @vinkla is it possible to contribute your work into composer?

[vinkla]

@mtangoo the Climb package wont work in Composer core but it would be nice if the functionality were somewhat similar.

[mtangoo]

Ok thanks. Does climb return Json? I don't want to poisone the thread but wanted to know just that

[vinkla]

@mtangoo not right now but it will in the future. If you've any more questions you can open an issue in the Climb repository.

[schmunk42]

For example, if package has version 2.5.0 and composer.json has ~2.4.4, we will not receive 2.5.0 update. That is what this proposal is about.

@Addvilz The ^ caret operator is supported since a while http://stackoverflow.com/a/22345808/291573 - shouldn't a package use this operator instead?

[Addvilz]

@schmunk42 that doesn't really affect the problem at hand, does it? No matter how you constrain your deps, you should be able to tell if a new version is available without running to packagist. :)

[schmunk42]

I think constraints are an important part to consider here, but I know what you mean.

A little helper for the bash...

composer show -Ni | xargs -n1 composer show | grep -E "name |version"

btw ... if there's an update available, which not matches your constraint, how should it be displayed?
There's almost always dev-master, but in the case you mentioned, there could be 2.5.0 and 3.0.0 available as an update. Would be nice, if we could list only newer stable versions.

[Addvilz]

@schmunk42 Perhaps, that could be managed using command line flags? For example "composer show-outdated --include-dev" would list latest versions including dev-master etc.

How I imagine this could work is that the command would show possible minor and patch increments for current major version and also list possible major version increments.

Consider the example:

Locked version: 1.3.3
Latest stable: 2.0.0
Versions also available: 1.3.9, 1.4.2
Versions listed as available for update: 1.3.9, 1.4.2, 2.0.0

This would give ability to decide to which one to update to. Also could be managed via cli switches.

Just from top of my head...

[Jeff-Lewis]

http://stackoverflow.com/questions/33528289/get-list-of-outdated-packages

[LastDragon-ru]

+1

[barryvdh]

So there already is an composer show command which shows the installed packages with current version in a table, I guess it wouldn't be too hard to extend that with composer show --outdated or composer show --versions or something which also shows the latest (stable) version available. Or perhaps even the latest version which matches your requirements (when you didn't update, instead of dry-run) + the latest stable.

[barryvdh]

Something like this? #5028
That atleast shows the recommend version to use.

[livingstonef]

Is there an official position on this issue? been waiting for this command for nearly a year now.

[curry684]

There's PR's with a lot of discussion, it's labeled 'Feature' and 'Nice to Have', what more official position do you want?

[livingstonef]

Last we heard was that there was a lot of talk about this but no contributions. But there are now and I will like to know what is the hold up here.

[curry684]

That the proposed implementation is flawed and that Composer 1.0 is in beta which means no big new features are added. You're welcome to submit a better PR though for after 1.0 final release.

[barryvdh]

Why is it flawed? Both #5028 and #5068 didn't actually receive any substantive feedback yet.

I can understand holding off until after 1.0 release, but why not provide any feedback on that then?

[curry684]

I was referring to #4517 not doing exactly what is wanted in all situations. There are multiple solutions right now and not really a clear path on which is best yet.

[Seb2nim]

@adragus-inviqa MY MISTAKE: I didn't read the full thread. I've removed my dummy +1.
My plusOne's goal was to say i think it would be a good thing to have it in composer core ; not reproaching anyone to not-having-implemented-it-yet. This not a free-store : it's open source and as i read and agree : lots of tasks/asks but few contributions.

Thread should be closed if the final position is to use a third-party plugin / tool for this. I think it can help to give my point-of-view regarding such a feature should be justified to be core or not.

I'll try to be more productive even if i'm not in my native language.

I'm using composer to manage Magento projects (Magento 1 in a home-made environment) and Wordpress based websites using the Bedrock stack (and combination of them).
I use fully qualified dependencies versions so this way i'm absolutely certain i can re-build the exactly same version at two points in time. I think it is safer than relying on unknown version number (supposes being very confident in packages providers regardless of regressions, etc..) I think it is a best practice for industry-level QA.

Drawback : i need to check available plugins updates by hand...

=> That would be cool to have it built-in : listing available updates for every package ignoring fully-qualified versions. I mention it because i think (maybe i'm wrong) that it would not be too hard to implement as composer ALREADY do it if using ^* things. That's my point, comma.

=> There is a third party solution : climb : great : I'll give a try to climb. End of transmission.

Thanks for reading

[Seldaek]

composer outdated (or composer show -l) is now available in the snapshot builds, composer self-update --snapshot if you wanna try it. Thanks to @barryvdh for the PR that made it and everyone else for the discussion and patience :)

[TomasVotruba]

Thank you @Seldaek