Live data from Hacker News

Which NPM package has the largest version number?

adamhl.dev

51–60 of 80 posts

Re: Which NPM package has the largest version number?

#51
post #45

Earlier quoted context omitted.

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?

Yes you can set price caps. The cost of a query is understandable ahead of time with the default pricing model ($6 per TB of data processed in a query). People usually get caught out by running expensive queries recursively. BigQuery is very cost effective and can be used safely.

Running ripgrep on my harddrive would cost me $48 at that price point.

Re: Which NPM package has the largest version number?

#52

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

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)

Re: Which NPM package has the largest version number?

#53

Earlier quoted context omitted.

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

I understood the list is ordered by biggest number, aka 189 > 172 > 161 > 159 > 120

I think in semver 0.4 usually means 0.04, not 0.40..., so it should be lower than 0.25.

Edit: nevermind, I misunderstood your point

Re: Which NPM package has the largest version number?

#54
post #43

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

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

Off the top of my head, CloudFlare uses a somewhat date based method of typing for their Workers types package, but it makes sense in context as you define compatibility dates for a Worker when you set it up, which automatically enables/disables potentially breaking features in the API.

https://www.npmjs.com/package/@cloudflare/workers-types

Re: Which NPM package has the largest version number?

#55
post #24

Earlier quoted context omitted.

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

Shouldn't vulnerabilities be "data" in this context? You bump the vulns database but keep the code at the same version if the logic is the same.

The particular problem here is if you started out doing it wrong then changing your update behavior would break everyone's scripting around it. By changing the 'code version' everyones CI/CD system just keeps working the same way as any other package.

Re: Which NPM package has the largest version number?

#56
post #45

Earlier quoted context omitted.

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?

Yes you can set price caps. The cost of a query is understandable ahead of time with the default pricing model ($6 per TB of data processed in a query). People usually get caught out by running expensive queries recursively. BigQuery is very cost effective and can be used safely.

You can tell someone has worked in the cloud for too long when they start to think of $6 per database query as a reasonable price.

Re: Which NPM package has the largest version number?

#60
post #35

Earlier quoted context omitted.

Shouldn't vulnerabilities be "data" in this context? You bump the vulns database but keep the code at the same version if the logic is the same.

If it's baked into the tool (can run offline) then it would be unavoidable, need a new version to get a new release on the package manager. 1.2.3 -> 1.2.3+1 (or +anything, date, whatever) could arguably be idiomatic semver though - that's what you do for packaging changes, like updating the description or categories to file it under etc. without actually changing the program.

> (can run offline)

And yet you need internet access when running the package with npx, even though the package is already locally installed.

At least, I can't use npx on so e of my VMs which do not have access to the internet. It just takes forever to atart (and I get annoyed after some minutes).

Post reply on HN