top | item 45245678

Which NPM package has the largest version number?

168 points| genshii | 5 months ago |adamhl.dev

76 comments

order

stabbles|5 months ago

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

breakingcups|5 months ago

Tangential, but I've only heard about BigQuery from people being surprised with gargantuan bills for running one query on a public dataset. Is there a "safe" way to use it with a cost limit, for example?

thesystemisbust|5 months ago

You can also query for free at clickpy.clickhouse.com. If you click on any of the links on the visuals you can see the query used.

The underlying dataset is hosted at sql.clickhouse.com e.g. https://sql.clickhouse.com/?query=U0VMRUNUIGNvdW50KCkgICBGUk...

disclaimer: built this a a while ago but we maintain this at clickhouse

oh and rubygems data is also there.

passivegains|5 months ago

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.

n4r9|5 months ago

> spanishconjugator [2], which consistently published ~240 releases per month between 2020 and 2024

They also stopped updating major and minor versions after hitting 2.3 in Sept 2020. Would be interesting to hear the rationale behind the versioning strategy. Feels like you might as well use a datetimestamp for the version.

0x500x79|5 months ago

deps.dev has a similar bigquery dataset across a couple more languages if someone wanted to do analysis across the other ecosystems they support.

jonchurch_|5 months ago

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/

bapak|5 months ago

> there are over 2800 legacy mixed-case packages, many of which have the same spelling as other existing lowercase packages

This is insane

BobbyTables2|5 months ago

Sounds like a typo-squatter’s paradise!

dotancohen|5 months ago

  > This is insane
Not for the JavaScript world.

I hate to deride the entire community, but many of the collective community decisions are smells. I think that the low barrier to entry means that the community has many inexperienced influential people.

sundarurfriend|5 months ago

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.

dotancohen|5 months ago

You might want to try a different storing strategy. 0.25 is above 0.4. These are, I believe, what are called in Unix flags "human numbers".

int_19h|5 months ago

This would seem to imply that the vast majority of Julia packages are 0.x?

aragonite|5 months ago

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|5 months ago

Isn’t vim or bash kinda like that? One of them publishes something like a few hundred patches on top the released tarball…

jve|5 months ago

Maybe that is intentional? Which package is it?

franky47|5 months ago

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

bapak|5 months ago

> People often assume that a zero-major version indicates that the software is not ready for production

I wonder why. Conventions that are being broken, maybe.

nosefurhairdo|5 months ago

The "winner" just had its 3000th release on GitHub, already a few patch versions past the version referenced in this article (which was published today): https://github.com/wppconnect-team/wa-version

genshii|5 months ago

After double-checking some things, the real winner is actually: https://github.com/nice-registry/all-the-package-names

I made a fairly significant (dumb) mistake in the logic for extracting valid semver versions. I was doing a falsy check, so if any of major/minor/patch in the version was a 0, the whole package was ignored.

The post has been updated to reflect this.

TZubiri|5 months ago

Brief reminder/clarification that these tools are used to circumvent WhatsApp ToS, and that they are used to:

1- Spam 2- Scam 3- Avoid paying for Whatsapp API (which is the only form of monetization)

And that the reason this thing gets so many updates is probably because of a mouse and cat game where Meta updates their software continuously to avoid these types of hacks and the maintainers do so as well, whether in automated or manual fashion.

oconnore|5 months ago

This package also seems to just have a misbehaving github action that is in a loop.

whilenot-dev|5 months ago

> 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

winrid|5 months ago

What's the benefit of promises like this here?

Just spin up a loop of 50 call chains. When one completes you just do the next on next tick. It's like 3 lines of code. No libraries needed. Then you're always doing 50 at a time. You can still use await.

async work() { await thing(); nextTick(work); }

for(to 50) { work(); }

then maybe a separate timer to check how many tasks are active I guess.

1gn15|5 months ago

Worried about being rate limited or DoSing the server.

genshii|5 months ago

Ah this is cool, thanks!

nailer|5 months ago

> 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.

athrowaway3z|5 months ago

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.

Taek|5 months ago

Each version is likely a new vulnerability that got submitted, doesn't seem that weird.

EdSchouten|5 months ago

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)?

genshii|5 months ago

There are plenty of larger ones and plenty of ones that used the date as the version, but I was mainly curious about packages that followed semver.

Any package version that didn't follow the x.y.z format was excluded, and any package that had less published versions than their largest version number was excluded (e.g. a package at version 1.123.0 should have at least 123 published versions)

rs186|5 months ago

Well, we are looking at npm packages, where every package is supposed to follow semantic versioning. The fact that we don't have date as version number means everyone is a good citizen.

https://docs.npmjs.com/about-semantic-versioning

tedk-42|5 months ago

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!

geetee|5 months ago

I wonder if the author could have replicated the couchdb database locally to make their life easier.

tantalor|5 months ago

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"?

joeyhage|5 months ago

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

AWS still made the top 50

zastai0day|5 months ago

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.

paulirish|5 months ago

`latentflip-test` is from the same fellow who did the "What the heck is the event loop anyway?" JSConf EU talk that many have seen. https://youtu.be/8aGhZQkoFbQ

kubatyszko|5 months ago

the one with -1 obviously ;)