Open jzabroski opened 4 years ago
These are all great ideas, thank you. I have really wanted to integrate the diff results with more of the UI and these are interesting ways to do that.
I'm a little unclear about the sidecar feature, but will re-read and think about it.
The basic idea is that nuget.com already supports uploading analyzers as packages. Pretty much the only special types nuget.com supports today are Tools (.NET CLI Tools) and Symbol Packages (snupkg format for debugging and source linking).
As an initial prototype, all you need to do is check if the package has a tag "packagelens=PackageName" and you'll know its meant to be a lens for a particular package. If it gains traction and popularity, it can then become a formal nuget.com standard. No other community in other languages has something like this. Smalltalk is probably the closest.
This is a Architecture Design RFC. Maybe this feature exists and I don't know how to use fuget.org properly, or missed some things when looking through the code.
I propose Package Vision, a marketing brand for a collection of services generalizing
ApiDiff
class, whereby we can write analysis tools on thePackageData
class. Each package analyzer will be called a Package Lens in the UI, as it would provide a unique view at the package assets.Potentially, Package Lenses could be uploaded to fuget.org as "sidecar" packages and tagged with which nuget.org packages they're intended to analyze. For example, if you've upgraded from one version of a library to another, and want to share your upgrades, you could use the output of the ApiDiff tool to describe how to resolve breaking changes you've found. In this sense, lenses are a collaborative tool with full access to the packages symbolic dependencies.
The key idea is that while the API Diff tool is great, I often want to answer specific questions, such as:
What was the last version of Autofac that can support
net461
?What was the last version of Autofac.Extensions.DependencyInjection that supported Autofac 4.9.4?
Are the transitive dependencies kept up-to-date?
Executable metadata suggesting its a Tool
Moving the
ApiDiff
logic to usePublicApiGenerator
project and allowing people to write scripts against the ApiDiff endpoint as if they were transparent remote procedure callsIs it safe to reference a netstandard2.0 TFM nuget package in an application with any of the following
TargetFrameworks
:netstandard2.1
;netcoreapp3.0
;netcoreapp3.1
?Is the package targeting netstandard2.0 TFM and netstandard2.1? If so, is it transitively pulling in dependencies that can be instead pulled in via
FrameworkReference
introduced in .NET Core 3.0?For each dll in the Nuget package, what does the PE Header say the AssemblyVersionAttribute is ?