4 ms·

It appears to be the 1000 packages with the highest PageRank, as pulled from https://anvaka.github.io/npmrank/ https://anvaka.github.io/npmrank/ So it's safe t

It appears to be the 1000 packages with the highest PageRank, as pulled from https://anvaka.github.io/npmrank/ https://anvaka.github.io/npmrank/ So it's safe to say that this package has the most transitive dependencies in npm.

OskarS 5y ago
If you wanna do this bad boy for real, you depend on this one and the next 999 packages. Actually, this can become a fun optimization problem. Which 1000 packages do you depend on to cover as much of NPM as possible?
- madeofpalk 5y ago
  I thought that's what this was.
  - koolba 5y ago
    Many of these packages have no dependencies. A new package that depends on this and anything not already downstream would have more dependencies.
- travisjungroth 5y ago
  Might get you close: Until you have 1000 Find the package not included that adds the most deps If it adds less than everything you have Add it Else Kick out anything that adds less than that And then make that a package and repeat as desired.
  - OskarS 5y ago
    Yeah, that's the greedy algorithm and it will probably take you pretty far, but there's no guarantee that it's optimal. What if the package has lots of dependencies, but they are already covered by other packages. Do you kick other packages out? Which ones? Or is it better to keep them in and add some other packages? This problem is almost certainly NP-complete (it's basically the the "set cover" problem from Karp's 21 NP-complete problems), so for something the size of NPM it's almost certainly infeasible. Your greedy version would probably get you a pretty nice result, though.
    - travisjungroth 5y ago
      I don't think it's optimal, but I tried to account for some of what you're saying. I'd take in whatever adds the most new dependencies if the amount it would add is lower or equal to the least contributing package I have. Otherwise, kick stuff out and recalculate.
- majjgepolja 5y ago
  If you wanna feel bad boy for real create a B+ tree of order 1000 which contains all npm packages in leaf nodes and create meta package for internal nodes. The root metapackage posted to HN.

OskarS 5y ago

If you wanna do this bad boy for real, you depend on this one and the next 999 packages. Actually, this can become a fun optimization problem. Which 1000 packages do you depend on to cover as much of NPM as possible?

madeofpalk 5y ago
I thought that's what this was.
- koolba 5y ago
  Many of these packages have no dependencies. A new package that depends on this and anything not already downstream would have more dependencies.
travisjungroth 5y ago
Might get you close: Until you have 1000 Find the package not included that adds the most deps If it adds less than everything you have Add it Else Kick out anything that adds less than that And then make that a package and repeat as desired.
- OskarS 5y ago
  Yeah, that's the greedy algorithm and it will probably take you pretty far, but there's no guarantee that it's optimal. What if the package has lots of dependencies, but they are already covered by other packages. Do you kick other packages out? Which ones? Or is it better to keep them in and add some other packages? This problem is almost certainly NP-complete (it's basically the the "set cover" problem from Karp's 21 NP-complete problems), so for something the size of NPM it's almost certainly infeasible. Your greedy version would probably get you a pretty nice result, though.
  - travisjungroth 5y ago
    I don't think it's optimal, but I tried to account for some of what you're saying. I'd take in whatever adds the most new dependencies if the amount it would add is lower or equal to the least contributing package I have. Otherwise, kick stuff out and recalculate.
majjgepolja 5y ago
If you wanna feel bad boy for real create a B+ tree of order 1000 which contains all npm packages in leaf nodes and create meta package for internal nodes. The root metapackage posted to HN.