HN Explorer

26 comments

[ 3.0 ms ] story [ 43.0 ms ] thread
geetee
I wonder if the author could have replicated the couchdb database locally to make their life easier.
nailer
> I was recently working on a project that uses the AWS SDK for JavaScript. When updating the dependencies in said project, I noticed that the version of that dependency was v3.888.0. Eight hundred eighty eight. That’s a big number as far as versions go.

It also isn’t the first AWS SDK. A few of us in… 2012 IIRC… wrote the first one because AWS didn’t think node was worth an SDK.

aragonite
Incidentally I once ran into a mature package that had lived in the 0.0.x lane forever and treated every release as a patch, racking up a huge version number, and I had to remind the maintainer that users depending with caret ranges won't get those updates automatically. (In semver caret ranges never change the leftmost non-zero digit; in 0.0.x that digit is the patch version, so ^0.0.123 is just a hard pin to 0.0.123). There may occasionally be valid reasons to stay on 0.0.x though (e.g. @types/web).
BobbyTables2
Isn’t vim or bash kinda like that? One of them publishes something like a few hundred patches on top the released tarball…
whilenot-dev
> Time to fetch version data for each one of those packages: ~12 hours (yikes)

The author could improve the batching in fetchAllPackageData by not waiting for all 50 (BATCH_SIZE) promises to resolve at once. I just published a package for proper promise batching last week: https://www.npmjs.com/package/promises-batched

athrowaway3z
One of the 'winners' I randomly googled.

> carrot-scan -> 27708 total versions

> Command-line tool for detecting vulnerabilities in files and directories.

I can't help but feel there is something absurd about this.

franky47
Anthony Fu’s epoch versioning scheme (to differentiate breaking change majors from "marketing" majors) could yield easy winners here, at least on the raw version number alone (not the number of sequential versions released):

https://antfu.me/posts/epoch-semver

stabbles
For Python (or PyPI) this is easier, since their data is available on Google BigQuery [1], so you can just run

    SELECT * FROM `bigquery-public-data.pypi.distribution_metadata` ORDER BY length(version) DESC LIMIT 10
The winner is: https://pypi.org/project/elvisgogo/#history

The package with most versions still listed on PyPI is spanishconjugator [2], which consistently published ~240 releases per month between 2020 and 2024.

[1] https://console.cloud.google.com/bigquery?p=bigquery-public-...

[2] https://pypi.org/project/spanishconjugator/#history

0x500x79
deps.dev has a similar bigquery dataset across a couple more languages if someone wanted to do analysis across the other ecosystems they support.
passivegains
I decided my life could not possibly go on until I knew what "elvisgogo" does, so I downloaded the tarball and poked around. it's a pretty ordinary numpy + pandas + matplotlib project that makes graphs from csv. one line jumped out at me: str_0 = ['refractive_index','Na','Mg','Al','Si','K','Ca','Ba','Fe','Type'] the university of st. andrews has a laser named "elvis" that goes on a remote controlled submarine: https://www.st-andrews.ac.uk/~bds2/elvislaser.htm I was hoping it'd be about go-go dancing to elvis music, but physics experiments on light in seawater is pretty cool too.
tedk-42
Large number of released packages due to renovatebot / dependabot patching + release automation!

If this was an actual measurement of productivity that bot deserves a raise!

zastai0day
Haha, good luck finding a real project that holds that title. It's always some squatted name, a dependency confusion experiment, or a troll publishing a package with version 99999.99999.99999 just to see what breaks. The "king" of that hill changes all the time. Just another day in the NPM circus.
EdSchouten
So 19494 is the largest? That's far lower than I expected. There's nobody out there that has put a date in a version number (e.g., 20250915)?
[deleted]
(comment deleted)
bapak
> there are over 2800 legacy mixed-case packages, many of which have the same spelling as other existing lowercase packages

This is insane

sundarurfriend
The Julia General registry is locally stored as a tar.gz and has version info for all registered packages, so I tried this out for Julia packages. The top 5 are:

    DiffEqBase                  6.189.1   
    LoopVectorization           0.12.172  
    Reactant                    0.2.161   
    Mooncake                    0.4.159   
    Distributions               0.25.120
So, no crazy numbers or random unknown packages, all are major packages that have just had a lot of work and history to them. Out of the top 10, pretty much half were from the SciML ecosystem.

Caveats/constraints: Like the post, this ignores non-SemVer packages (which mostly used date-based versions) and also jll (binary wrapper) packages which just use their underlying C libraries' versions. Among jlls, the largest that isn't a date afaict is NEO_jll with 25.31.34666+0 as its version.

int_19h
This would seem to imply that the vast majority of Julia packages are 0.x?
sundarurfriend
There are many that are, but I feel like your comment is based on the same faulty assumption as your sibling comment - that this is an ordering of version numbers as a whole. It's not, the ordering is on the same basis as in the post, the largest single number within the MAJOR.Minor.patch trio.
jonchurch_
The author has run into the same problem that anyone who wants to do analysis on the NPM registry runs into, there's just no good first party API for this stuff anymore.

It seems this was their first time going down this rabbit hole, so for them and anyone else, I'd urge you to use the deps.dev Google BigQuery dataset [0] for this kind of analysis. It does indeed include NPM and would have made the author's work trivial.

Here's a gist with the query and the results https://gist.github.com/jonchurch/9f9283e77b4937c8879448582b...

[0] - https://docs.deps.dev/bigquery/v1/

joeyhage
> 46. aws-sdk -> 1692 (2.1692.0)

AWS still made the top 50

tantalor
I'm glad "all-the-package-names" includes "all-the-package-names"

But what if it was "all-the-package-names-that-do-not-reference-themselves"?