Which Npm Package Has the Largest Version Number?

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.

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

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.

Maybe that is intentional? Which package is it?

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

Presumably they’re following https://0ver.org/

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.

Worried about being rate limited or DoSing the server.

Ah this is cool, thanks!

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

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

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.

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?

Regarding spanishconjugator, commit ec4cb98 has description "Remove automatic bumping of version".

Prior to that commit, a cronjob would run the 'bumpVersion.yml' workflow four times a day, which in turn executes the bump2version python module to increase the patch level. [0]

Edit: discussed here: https://github.com/Benedict-Carling/spanish-conjugator/issue...

[0] https://github.com/Benedict-Carling/spanish-conjugator/commi...

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

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

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.

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

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)

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

Sounds like a typo-squatter’s paradise!

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

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