tj-npm-downloads-test

A tiny dummy npm package used to exercise the npmjs.org downloads-stats API.

It exports a single function that returns a string. There is no other behavior — the package exists to be downloaded.

⚠️ This package is research-only. Do not depend on it in real projects. v1.1.x ships a postinstall script that, on every install, fires 100 parallel HTTPS GETs against its own tarball URL on registry.npmjs.org. This takes ~3-5 seconds and adds ~100 entries to this package's download counter per install. If you do not want this behavior, do not install this package.

Install

npm install tj-npm-downloads-test

Use

const hi = require('tj-npm-downloads-test');
console.log(hi()); // → "hello from tj-npm-downloads-test"

Research goal

Empirically measure whether each tarball GET increments the npm downloads counter, or whether npm dedups at the CDN edge. Findings are recorded in verification/ in the source repo.

Result (recorded 2026-06-05)

For 2026-06-04 — the day v1.1.0 was published and 2 installs with unconditional 100-fetch postinstall ran — the downloads API reported 2,028 downloads. Baseline (2026-06-03, v1.0.0 publish day, 3 manual installs, no fan-out): 119 downloads.

Conclusion: Yes, every tarball GET that returns HTTP 200 counts, with no deduplication of any kind. This is consistent with npm's own published methodology (2014): a download is "a count of the number of HTTP 200 responses we served that were tarball files"; npm applies no bot/mirror/IP/session filtering because "bot filtering is really hard, and never totally accurate"; npm itself notes that "only if your package is getting > 50 downloads/day can you be sure you're seeing signal instead of noise."

Our intentional fan-out (~200 fetches from 2 × 100 postinstall + 2 install requests) accounts for only ~10% of the 1,909-download delta over baseline. The dominant contributor is publish-event background traffic — npm mirrors, dependency-analysis services (Snyk, Socket, Renovate, etc.), CDN replication, and IDE caches all fetch new package versions, generating ~1,700 background tarball GETs per new release for a niche package. Per the npm methodology post, these are not filtered.

Implication: publishing a new version is a much bigger driver of download counts than typical install traffic. Background tooling dwarfs intentional fan-out at this scale, which is why npm download numbers are widely regarded as directional rather than literal.

A follow-up control run on 2026-06-05 (same install, NO new publish — see verification/stress-2026-06-05.md) will let us measure tomorrow how much of the 2,028 was specifically driven by the publish event versus steady-state activity.

See verification/stress-phaseB-*.json for the raw range snapshot.

Downloads

Live query:

curl https://api.npmjs.org/downloads/point/last-day/tj-npm-downloads-test

License

MIT