Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Show aggregate information about package dependencies #10078

Open
lostmsu opened this issue Jul 22, 2024 · 5 comments
Open

[Feature]: Show aggregate information about package dependencies #10078

lostmsu opened this issue Jul 22, 2024 · 5 comments
Labels
feature-request Customer feature request Triaged

Comments

@lostmsu
Copy link

lostmsu commented Jul 22, 2024

Related Problem

The well-known problem of NPM package bloat.

The Elevator Pitch

When I am looking for packages, information like download size of the package itself is insufficient to make an informed decision.

It would be nice to have the following information on the main package page:

  • total size of all dependencies
  • number of transitive dependencies

Additional Context and Details

No response

@lostmsu lostmsu added the feature-request Customer feature request label Jul 22, 2024
@joelverhagen
Copy link
Member

I like this idea. One issue with calculating these metrics (total size on disk, number of nodes in the graph) is that transitive dependencies of a package vary per target framework.

Said another way, these numbers will be different if you're restoring for .NET Framework 4.7.2 vs. .NET 8.0. So either we'd need to pick the one target framework to show this number for or show a useful variety.

Generally, NuGet.org has avoided simulating a package restore operations (i.e. exploring the transitive dependencies) and just looks at each package individually. We'd need some careful controls and handling of edge cases. For example it's possible to have a package on NuGet.org whose transitive dependency is NOT on nuget.org (not yet, due to timing of package publishing, or it will never be there due to a publisher error or by design -- some other feed).

For "total size of all dependencies", this could have several interpretations. Do you mean the cumulative size of the .nupkg per transitive dependency? Or the extracted size on disk after restore? Or perhaps just the package assets that end up in your bin directory?

@lostmsu
Copy link
Author

lostmsu commented Jul 25, 2024

Either size of .nupkg as-is, or its extracted size.

@erdembayar
Copy link
Contributor

One problem I see is graph is not deterministic it depends on available transitive dependencies and tfm version, they're always in motion. Sometimes new versions are published and old ones are unlisted.
Also same dependencies are shared across many direct dependencies, so it's hard to give accurate number on size.

@erdembayar
Copy link
Contributor

@lostmsu
Is npm results are deterministic ? Does it change over time?

@lostmsu
Copy link
Author

lostmsu commented Jul 25, 2024

I am not sure what is the best approach for handling TFMs, but just want to remind that perfect is the enemy of good. E.g. it does not have to be exact. So I'd propose to start with:

long Size(Pkg pkg) => pkg.NuPkgFile.Size;

Set Dependencies(Pkg pkg) {
  var deps = new Set();
  foreach (var tfm in pkg.TFMs) {
    var tfmDeps = pkg.Dependencies[tfm];
    foreach (Pkg dep in tfmDeps)
      if (deps.Add(dep)) deps.Union(Dependencies(dep));
  }
  return deps;
}

long TotalSize(Pkg pkg)
  => Size(pkg) + Dependencies(pkg).Select(Size).Sum();

long DepCount(Pkg pkg) => Dependencies(pkg).Count;

Only calculate when the package version is uploaded and don't update later.

UPD. one thing missing above is kicking out old versions from the deps set when a newer one is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Customer feature request Triaged
Projects
None yet
Development

No branches or pull requests

3 participants