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.

[kevinkuszyk]

@anangaur @nkolev92, fyi, from the npm docs:

• wanted is the maximum version of the package that satisfies the semver range specified in package.json. If there's no available semver range (i.e. you're running npm outdated --global, or the package isn't included in package.json), then wanted shows the currently-installed version.
• latest is the version of the package tagged as latest in the registry. Running npm publish with no special configuration will publish the package with a dist-tag of latest. This may or may not be the maximum version of the package, or the most-recently published version of the package, depending on how the package's developer manages the latest dist-tag.
• location is where in the dependency tree the package is located. Note that npm outdated defaults to a depth of 0, so unless you override that, you'll always be seeing only top-level dependencies that are outdated.

For nuget, I see location as the project. If you run nuget outdated from a solution root, it would be useful to see which project each package is used in.

HTH.

[shanselman]

I so very much want this. It's the NuGet spiritual "npm check"

[anangaur]

This feature can tied with the deprecation feature: #2867 i.e. the same command should be able to flag the deprecated feature along with the reason why a particular package in use is deprecated - obsolete | vulnerable | inactive etc.

[blowdart]

And of course this needs linked to the nice deprecated feed I want as its source

[DanWallaceAdslot]

Nice. I was following the dupe PR. I ended up writing a powershell script that just parses packages.config, hits our repo for each package and checks the version there.

That being said, could there be an option to specify multiple repo's (as we have private ones with our own packages on there). --repos=repo1.com,repo2.com or would this just read from the config and do all enabled ones by default?

[anangaur]

@blowdart What do you mean by deprecated feed?

[anangaur]

Here is write up on the outdated command - mostly a summary of what has been discussed so far in the issue. Feel free to point out any missing element(s).

Spec: Show outdated packages

[anangaur]

@DanWallaceAdslot The outdated command is supposed to run on the project/solution and list out the outdated packages that need an update. I am not sure whatda you mean by specifying repos in here? Do you mean package repos? If so, NuGet will just use those listed in the nuget.config

[nkolev92]

I don't see a problem with having a --source param on the command.

However, we don't recommend having variable sources across NuGet commands (specifically restore).

Even with a lock file, using different sources among different commands will lead to a confusing behavior, where the resolved package versions vary because of differences on the feeds (when updating the lock file).

There's a use case for --source in this case though.

[kjbetz]

Here's an old issue I suggested a while ago (https://github.com/dotnet/cli/issues/7483) ... Please make this happen. It's not really helpful to just show me what's outdated. If you can "just" implement the way yarn does it, it would be awesome.

yarn upgrade
https://yarnpkg.com/lang/en/docs/cli/upgrade/

And more importantly, yarn upgrade-interactive
https://yarnpkg.com/lang/en/docs/cli/upgrade-interactive/

Also, this for reference: npm update
https://docs.npmjs.com/cli/update

[DanWallaceAdslot]

@anangaur Sorry, my terminology is all over the place. I was referring to the packageSources inside NuGet.config and was wondering about a filter. Thanks for clearing it up and ignore my comment :)

[tmds]

related #6848 is about a package being able to declare it has patch releases (with semver semantics). That metadata can be used to automatically roll-forward patch versions, e.g. during the restore operation.

[anangaur]

@kjbetz What you are asking is an update command that does not exist today let alone an interactive one. We will get there and implementing an outdated command will be a step in that direction.

[anangaur]

Some functionality of outdated have been incorporated in the dotnet list command as speced here: https://github.com/NuGet/Home/wiki/dotnet-list-package

[AnthonySteele]

This is great.

I would like to have either a function that I can call from my code to get all of this info, or failing that, the data output in an easily machine-readable format

I would like sufficient data to calculate the "libyear" metric amongst others

[derek126]

ETA?

[anangaur]

@derek126 the functionality of outdated is available today with dotnet list package —outdated command. https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-list-package

Is this what you are looking for?

[anangaur]

@rrelyea i believe we should close this issue and open another one to track the list functionality outputting a json or other machine readable format.

[nkolev92]

I agree with @anangaur

As a side note, there already is an issue tracking a machine readable output for the list command.
#7752