.png)
2 hours ago
1
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.
That got me thinking. I wonder what package in the npm registry has the largest number in its version. Could be a major, minor, or patch version, and it doesn’t have to be the latest version of the package. In other words, out of the three numbers in <major>.<minor>.<patch> for each version for each package, what is the largest number I can find?
TL;DR? Jump to the results to see the answer.
The npm API
Obviously npm has some kind of API, so it shouldn’t be too hard to get a list of all… 3,639,812 packages. Oh. That’s a lot of packages. Well, considering npm had 374 billion package downloads in the past month, I’m sure they wouldn’t mine me making a few million HTTP requests.
Doing a quick search search for “npm api” leads me to a readme in the npm/registry repo on GitHub. There’s a /-/all endpoint listed in the table of contents which seems promising. That section doesn’t actually exist in the readme but maybe it still works?
1
$ curl 'https://registry.npmjs.org/-/all'
2
{"code":"ResourceNotFound","message":"/-/all does not exist"}
Whelp, maybe npm packages have an ID and I can just start at 1 and count up? It looks like packages have an _id field… never mind, the _id field is the package name. Okay let’s try to find something else.
A little more digging brings me to this GitHub discussion about the npm replication API. So npm replicates package info in CouchDB at https://replicate.npmjs.com, and conveniently they support the _all_docs endpoint. Let’s give that a try:
1
$ curl 'https://replicate.npmjs.com/registry/_all_docs'
2
{
3
"total_rows" : 3628088,
4
"offset" : 0,
5
"rows" : [
6
{
7
"id" : "-",
8
"key" : "-",
9
"value" : {
10
"rev" : "5-f0890cdc1175072e37c43859f9d28403"
11
}
12
},
13
{
14
"id" : "--------------------------------------------------------------------------------------------------------------------------------whynunu",
15
"key" : "--------------------------------------------------------------------------------------------------------------------------------whynunu",
16
"value" : {
17
"rev" : "1-1d26131b0f8f9702c444e061278d24f2"
18
}
19
},
20
{
21
"id" : "-----hsad-----",
22
"key" : "-----hsad-----",
23
"value" : {
24
"rev" : "1-47778a3a6f9d8ce1e0530611c78c4ab4"
25
}
26
},
27
# 997 more packages...
Those are some interesting package names. Looks like this data is paginated and by default I get 1,000 packages at a time. When I write the final script, I can set the limit query parameter to the max of 10,000 to make pagination a little less painful.
Fortunately the CouchDB docs have a guide for pagination, and it looks like it’s as simple as using the skip query parameter.
1
$ curl 'https://replicate.npmjs.com/registry/_all_docs?skip=1000'
2
"Bad Request"
Never mind, according to the GitHub discussion linked above, skip is no longer supported. The “Paging (Alternate Method)” section of the same page says that I can use startkey_docid instead. If I grab the id of the last row, I should be able to use that to return the next set of rows. Fun fact, the 1000th package (alphabetically) on npm is 03-webpack-number-test.
1
$ curl 'https://replicate.npmjs.com/registry/_all_docs?startkey_docid="03-webpack-number-test"'
2
{
3
"total_rows" : 3628102,
4
"offset" : 999,
5
"rows" : [
6
# another 1000 packages...
Nice. Also, another 3628102 - 3628088 = 14 packages have been published in the ~15 minutes since I ran the last query.
There’s one more piece of the puzzle to figure out. How do I get all the versions for a given package? Unfortunately, it doesn’t seem like I can get package version information along with the base info returned by _all_docs. I have to separately fetch each package’s metadata from https://registry.npmjs.org/<package_id>. Let’s see what good ol’ trusty 03-webpack-number-test looks like:
1
$ curl 'https://registry.npmjs.org/03-webpack-number-test'
2
{
3
# i've omitted some fields here
4
"_id" : "03-webpack-number-test",
5
"versions" : {
6
"1.0.0" : { ... },
7
# the rest of the versions...
Alright, I have everything I need. Now I just need to write a bash script that—just kidding. A wise programmer once said “if your shell script is more than 10 lines, it shouldn’t be a shell script” (that was me, I said that). I like TypeScript, so let’s use that.
The biggest bottleneck is going to be waiting on the GETs for each package’s metadata. My plan is this:
- Grab all the package IDs from the replication API and save that data to a file (I don’t want to have to refetch everything if the something goes wrong later in the script)
- Fetch package data in batches so we’re not just doing 1 HTTP request at a time
- Save the package data to a file (again, hopefully I only have to fetch everything once)
Once I have all the package data, I can answer the original question of “largest number in version” and look at a few other interesting things.
(A couple hours and many iterations later…)
1
$ bun npm-package-versions.ts
2
Fetching package IDs...
3
Fetched 10000 packages IDs starting from offset 0
4
# this goes on for a while...
5
Finished fetching package IDs
6
Fetched 50 packages in 884ms (57 packages/s)
7
Fetched 50 packages in 852ms (59 packages/s)
8
# this goes on for a really long while...
See the script section at the end to if you want to see what it looks like.
Results
Some stats:
- Time to fetch all ~3.6 million package IDs: A few minutes
- Time to fetch version data for each one of those packages: ~12 hours (yikes)
- Packages fetched per second: ~84 packages/s
- Size of package-ids.json: ~78MB
- Size of package-data.json: ~886MB
And the winner is… (not really) latentflip-test at version 1000000000000000000.1000000000000000000.1000000000000000000. And no, there haven’t actually been one quintillion major versions of this package published. Disappointing, I know.
Well, I feel like that shouldn’t count. I think we can do better and find a “real” package that actually follows semantic versioning. I think a better question to ask is this:
For packages that follow semantic versioning, which package has the largest number from <major>.<minor>.<patch> in any of its versions?
So, what does it mean to “follow semantic versioning”? Should we “disqualify” a package for skipping a version number? In this case, I think we’ll just say that a package has to have more versions published than the largest number we find for that package. For example, a package with a version of 1.888.0 will have had at least 888 versions published if it actually followed semver.
Before we get to the real winner, here are the top 10 packages by total number of versions published:
1
electron-remote-control -> 37328 total versions
2
@npm-torg/public-scoped-free-org-test-package-2 -> 37134 total versions
3
public-unscoped-test-package -> 27719 total versions
4
carrot-scan -> 27708 total versions
5
@npm-torg/public-test-package-2 -> 27406 total versions
6
@octopusdeploy/design-system-components -> 26724 total versions
7
@octopusdeploy/type-utils -> 26708 total versions
8
@octopusdeploy/design-system-tokens -> 22122 total versions
9
@mahdiarjangi/phetch-cli -> 19498 total versions
10
@atlassian-test-prod/hello-world -> 19120 total versions
Top 10 packages that (probably) follow semver by largest number in one of its versions:
1
electron-remote-control -> 19065 (1.2.19065)
2
@atlassian-test-prod/hello-world -> 16707 (9.7.16707)
3
@octopusdeploy/design-system-components -> 14274 (2025.3.14274)
4
@octopusdeploy/type-utils -> 14274 (2025.3.14274)
5
@octopusdeploy/design-system-tokens -> 14274 (2025.3.14274)
6
@atlassian-test-staging/test -> 13214 (49.4.13214)
7
binky -> 9906 (3.4.9906)
8
kse-visilia -> 5997 (1.6.5997)
9
@idxdb/promised -> 4614 (2.3.4614)
10
wix-style-react -> 4264 (1.1.4264)
So it seems like the winner is electron-remote-control, right? Unfortunately, I’m not going to count that either. It only has so many versions because of a misconfigured GitHub action that ran every hour… for a while.
I manually went down the above list, disqualifying any packages that had similar issues. I also checked that “new” versions actually differed from previous versions in terms of content. Overall, I looked for a package that was actually publishing new versions on purpose with some kind of change to the package content.
The real winner (#20 on the list) is: @wppconnect/wa-version at version 1.5.2219.
What you do with this extremely important and useful information is up to you.
Script
1
/* This script uses Bun specific APIs and should be executed directly with Bun */
2
3
import fs from "node:fs/promises"
4
import process from "node:process"
5
6
async function main() {
7
const NUM_TO_PRINT = 20
8
9
const packageIds = await fetchPackageIds()
10
const packageData = await fetchAllPackageData(packageIds)
11
const normalizedPackageData = normalizePackageData(packageData)
12
13
const packagsByNumOfVersions = packageData.toSorted((a, b) => b.versions.length - a.versions.length) // don't use normalizedPackageData here because it *only* includes valid semver versions
14
const packagesByLargestNumber = normalizedPackageData.toSorted((a, b) => b.largestNumber.num - a.largestNumber.num)
15
16
// Ignore packages where the number of versions isn't greater than the largest number.
17
// For example, a package with a version of 1.888.0 will have had *at least* 888 versions published if it actually followed semver.
18
const packagesWithSemverByLargestNumber = packagesByLargestNumber.filter(
19
(pkg) => pkg.versions.length >= pkg.largestNumber.num,
20
)
21
const packagesWithoutKnownBadByLargestNumber = packagesWithSemverByLargestNumber.filter((pkg) =>
22
KNOWN_BAD_PACKAGES.every((badId) => !pkg.id.startsWith(badId)),
23
)
24
25
console.log(`\nTop ${NUM_TO_PRINT} packages by total number of versions published:`)
26
for (const { id, versions } of packagsByNumOfVersions.slice(0, NUM_TO_PRINT)) {
27
console.log(`${id} -> ${versions.length} total versions`)
28
}
29
30
const logPackagesByLargestNumber = (packages: NormalizedPackageData[]) => {
31
for (const { id, largestNumber } of packages.slice(0, NUM_TO_PRINT)) {
32
console.log(`${id} -> ${largestNumber.num} (${largestNumber.version})`)
33
}
34
}
35
36
console.log(`\nTop ${NUM_TO_PRINT} packages by largest number in version:`)
37
logPackagesByLargestNumber(packagesByLargestNumber)
38
39
console.log(`\nTop ${NUM_TO_PRINT} packages that follow semver by largest number in version:`)
40
logPackagesByLargestNumber(packagesWithSemverByLargestNumber)
41
42
console.log(
43
`\nTop ${NUM_TO_PRINT} packages that follow semver by largest number in version (excluding known bad packages):`,
44
)
45
logPackagesByLargestNumber(packagesWithoutKnownBadByLargestNumber)
46
47
console.log("\nDone!")
48
}
49
50
/**
51
* These are packages that have a large number of versions because of some automation (e.g. GitHub Action), where each "new" version was identical to the last.
52
* For example, 'electron-remote-control' was publishing a version every hour for a long time due to a configuration mistake.
53
*/
54
const KNOWN_BAD_PACKAGES = [
55
"electron-remote-control",
56
"carrot-scan",
57
"@atlassian-test",
58
"@octopusdeploy",
59
"binky",
60
"kse-visilia",
61
"intraactive-sdk-ui",
62
"@idxdb/promised",
63
"wix-style-react",
64
"sale-client",
65
"botfather",
66
"electron-i18n",
67
"warframe-items",
68
"ebt-vue",
69
"@geometryzen/jsxgraph",
70
"eslint-config-innovorder-v2",
71
"@innovorder/serverless-resize-bucket-images",
72
"@xuda.io/xuda-worker-bundle",
73
"@abtasty/pulsar-common-ui",
74
]
75
76
/**
77
* Fetches every single package ID from the npm replicate API and writes the data to a file.
78
*/
79
async function fetchPackageIds(): Promise<string[]> {
80
const packageIdsFile = Bun.file("package-ids.json")
81
// return the existing package IDs if they exist
82
if (await packageIdsFile.exists()) {
83
console.log("Using existing package IDs")
84
return (await packageIdsFile.json()) as string[]
85
}
86
87
console.log("Fetching package IDs...")
88
let firstFetch = true
89
let startKeyPackageId: string | undefined
90
const packageIds: string[] = []
91
92
// We use the last package ID of current fetch as the start key for the next fetch. Once the start key is the same as the last package ID, we've fetched all packages and can break out of the loop.
93
while (true) {
94
const LIMIT = 10_000
95
const startKeyQueryParam = firstFetch ? "" : `&startkey_docid="${startKeyPackageId}"`
96
const json = await fetchJson<{ rows: { id: string }[]; offset: number }>(
97
`https://replicate.npmjs.com/registry/_all_docs?limit=${LIMIT}${startKeyQueryParam}`,
98
)
99
if (!json) process.exit(1) // Stop the script if we fail to fetch package IDs. The error will have already been logged.
100
101
const { rows, offset } = json
102
console.log(`Fetched ${rows.length} package IDs starting from offset ${offset}`)
103
104
for (const { id: packageId } of rows) {
105
if (startKeyPackageId === packageId) continue // Skip the startKeyPackageId. The startKeyPackageId is already in the list because it's the same as the last package ID from the previous fetch
106
packageIds.push(packageId)
107
}
108
109
const lastPackageId = rows.at(-1)?.id
110
if (startKeyPackageId === lastPackageId) break // we've reached the end of the package IDs
111
112
startKeyPackageId = lastPackageId
113
114
firstFetch &&= false
115
}
116
117
console.log("Finished fetching package IDs")
118
console.log(`Writing package IDs to '${packageIdsFile.name}'...`)
119
await packageIdsFile.write(JSON.stringify(packageIds))
120
console.log(`Finished writing package IDs to '${packageIdsFile.name}'`)
121
122
return packageIds
123
}
124
125
interface PackageData {
126
id: string
127
versions: string[]
128
}
129
130
/**
131
* Fetches all package metadata from the npm registry API and writes the data to a file.
132
*/
133
async function fetchAllPackageData(packageIds: string[]): Promise<PackageData[]> {
134
/** The number of packages to fetch at once */
135
const BATCH_SIZE = 50
136
137
interface FetchedPackageData {
138
_id: string
139
versions?: Record<string, unknown> // when we fetch package data, sometimes the versions object is missing
140
}
141
142
const packageDataFile = Bun.file("package-data.json")
143
// return the existing package data if it exists
144
if (await packageDataFile.exists()) {
145
console.log("Using existing package data")
146
return (await packageDataFile.json()) as PackageData[]
147
}
148
149
console.log("Fetching package data...")
150
const allPackageData: PackageData[] = []
151
152
while (packageIds.length > 0) {
153
const startTime = Date.now()
154
155
const batch = packageIds.splice(0, BATCH_SIZE)
156
157
const packageDataPromises = batch.map(async (packageId) => {
158
const fetchedPackageData = await fetchJson<FetchedPackageData>(
159
`https://registry.npmjs.org/${encodeURIComponent(packageId)}`,
160
)
161
if (!fetchedPackageData) return
162
const { _id, versions = {} } = fetchedPackageData // default versions to an empty object if it doesn't exist
163
const packageData: PackageData = { id: _id, versions: Object.keys(versions).reverse() } // reverse the versions array so the newest version is first
164
return packageData
165
})
166
const packageData = (await Promise.all(packageDataPromises)).filter((data) => data !== undefined)
167
168
allPackageData.push(...packageData)
169
170
const endTime = Date.now()
171
const duration = endTime - startTime
172
console.log(
173
`Fetched ${packageData.length} packages in ${duration}ms (${Math.round((packageData.length / duration) * 1000)} packages/s)`,
174
)
175
}
176
177
console.log("Finished fetching package data")
178
console.log(`Writing package data to '${packageDataFile.name}'...`)
179
await packageDataFile.write(JSON.stringify(allPackageData))
180
console.log(`Finished writing package data to '${packageDataFile.name}'`)
181
182
return allPackageData
183
}
184
185
type SemverNumbers = [number, number, number]
186
interface NormalizedPackageData {
187
id: string
188
largestNumber: {
189
num: number
190
version: string
191
}
192
versions: SemverNumbers[]
193
}
194
195
/**
196
* Transforms package data so that it includes the largest number from all of its versions.
197
* In each `versions` array, only valid semver versions are kept.
198
*/
199
function normalizePackageData(packageData: PackageData[]): NormalizedPackageData[] {
200
console.log("Getting normalized package data...")
201
const normalizedPackageData = packageData
202
.map((pkg) => {
203
const semverVersions = pkg.versions
204
.map((version) => splitSemver(version))
205
.filter((version) => version !== undefined)
206
if (semverVersions.length === 0) return // if the package didn't have any valid semver versions, don't include it
207
208
let largestNumber = { num: 0, version: "" }
209
for (const semver of semverVersions) {
210
const [major, minor, patch] = semver
211
const num = Math.max(major, minor, patch)
212
if (num > largestNumber.num) largestNumber = { num, version: semver.join(".") }
213
}
214
215
const normalizedPackage = { id: pkg.id, largestNumber, versions: semverVersions }
216
return normalizedPackage
217
})
218
.filter((pkg) => pkg !== undefined)
219
220
console.log("Finished getting normalized package data")
221
222
return normalizedPackageData
223
}
224
225
await main()
226
227
/* UTILS */
228
229
/**
230
*
231
* Splits a valid semver string into an array of three number: `[major, minor, patch]`
232
* If the string is not a valid semver, `undefined` is returned.
233
*/
234
function splitSemver(version: string): SemverNumbers | undefined {
235
const versionParts = version.split(".").map((part) => Number.isInteger(Number(part)) && Number.parseInt(part, 10))
236
if (versionParts.length !== 3) return
237
const [major, minor, patch] = versionParts
238
if (!(major && minor && patch)) return
239
return [major, minor, patch]
240
}
241
242
/**
243
* Calls `console.error` with the message and appends the message to a `error.log` file.
244
*/
245
function logError(message: string) {
246
console.error(message)
247
fs.appendFile("error.log", message)
248
}
249
250
/**
251
* Fetches the url and returns the JSON response object. Calls {@link logError} and returns `undefined` instead of throwing if an error occurs.
252
*/
253
async function fetchJson<T>(url: string): Promise<T | undefined> {
254
try {
255
const response = await fetch(url)
256
if (!response.ok) throw new Error(`(${response.status}) ${await response.text()}`)
257
return (await response.json()) as T
258
} catch (error) {
259
const errorMessage = error instanceof Error ? error.message : String(error)
260
logError(`something went wrong fetching json for '${url}': ${errorMessage}`)
261
}
262
263
return
264
}
