NuGet outdated, check or equivalent functionality

[AndrewGretton]

Update by @anangaur:

Spec: Show outdated packages (Status: Incubation)

---

We often find ourselves wishing to do a task during CI, that is only possible with cmdlets available in the package management console. Obviously these cmdlets can't run as part of CI, so we're stuck. Our most recurring painpoint is working out what package updates are available, without actually making modifications - this would let us:

• Report on out of date packages
• Flag up new major version availability
• Fail builds, if packages we consider to be critical are no longer up to date

I've submittted a PR with an example naive implementation of this here: NuGet/NuGet.Client#1649

Would others find this type of feature useful?

[emgarten]

Thanks for the PR @AndrewGretton, for the update command that change does look handy.

Do you think it would make more sense to have a new command to find outdated packages? My concern here is that update only works for packages.config while NuGet is moving to PackageReference.

[rrelyea]

yes, we'd want this to work for all project types, not just packages.config.

[kevinkuszyk]

@nkolev92 I'm posting here to continue the conversation from #3415.

@kevinkuszyk If you're still willing to devote some to this, we'll be happy to work through a design.

I have a hack week coming up soon, so I should be able to spend some time on implementation then. In the meantime I'm happy to discuss ideas and agree what the functionality should be.

It looks like the OP here is suggesting adding a -whatif flag the existing nuget update command, whereas #3415 was about adding a new nuget outdated command. Is there a preference at your end? I would prefer a new command, but I see the argument for adding a flag to the existing one.

Also, any thoughts on output? This is my inital idea based on npm outdated:

Package                Current     Wanted      Latest    Location
EntityFramework        6.1.2       6.1.2       6.2       SomeProject.Data
NUnit                  2.4.0       2.6.4       3.8.1     SomeProject.UnitTests

[nkolev92]

@kevinkuszyk
Personally I am a fan of a new command, "nuget outdated", as it aligns to what NPM, RVM are doing,
But I'd like to ask for the team to chip in on their behalf. @NuGet/nuget-client

A few important things about this feature.

1. It has to work for both package reference and packages.config.
2. This has to be cross-plat (most of our libraries are), as we think it'll be super important to have in the dotnet.exe as well.

There's lots of other details that we'd need to consider, like the handling of transitive packages in package reference etc.

What's the location bit supposed to be? Project?
The way I see it'll be something like this.

nuget.exe outdated <projectName>

<projectName>
Package                Current     Wanted      Latest   
EntityFramework        6.1.2       6.1.2       6.2.0   
NUnit                  2.4.0       2.6.4       3.8.1  

Another thing is, do we want to display the versions of transitive packages.
The consumer does not really have control of transitive packages yet...if they want to control the version there, they'd need to add it as a top level dependency.
So i think it should be there...but it should be obvious that it's a transitive package.

[anangaur]

What is 'Wanted'? Who wants it? 😀

[nkolev92]

@anangaur
Specified, declared :)

It's the npm nomenclature, didn't think too hard about it :D

[kevinkuszyk]

@anangaur

What is 'Wanted'? Who wants it? 😀

I read it that I have a version constraint, or I've pinned a package to a specific version. In the example above for NUnit:

Package                Current     Wanted      Latest   
NUnit                  2.4.0       2.6.4       3.8.1 

• I have 2.4.0 installed.
• It will upgarde to 2.6.4 (in my packages.config I have it constrained with allowedVersions="(,3)").
• 3.8.1 is the latest on nuget.org, but I won't be getting that.

As @nkolev92 notes, it's inspired by npm.