Description
The registry npm proxy advertises a latest dist-tag for @tsci/x4132.sht40_ad1b_r2 but serves an empty versions map, so the package can be found but never installed.
$ bun add @tsci/x4132.SHT40_AD1B_R2
error: Package "@tsci/x4132.SHT40_AD1B_R2" with tag "latest" not found, but package exists
Steps to reproduce
- Search the registry for "sht4" —
x4132/SHT40_AD1B_R2 comes back (package search API, and it has a normal package page).
bun add @tsci/x4132.SHT40_AD1B_R2 (or the lowercase name) in any project → the error above.curl https://npm.tscircuit.com/@tsci%2fx4132.sht40_ad1b_r2 shows the inconsistency directly:
{"name":"@tsci/x4132.sht40_ad1b_r2","dist-tags":{"latest":"0.1.0"}, ..., "versions":{}}The registry API itself knows the release: package_releases/list returns version 0.1.0 created 2025-08-26, same timestamp as the package. So this isn't a package that was never published — the release exists but the npm proxy has nothing installable for it (possibly a build/transpile that never completed; has_transpiled_code is null on the release).
Why it hurts
This was the only SHT40 sensor package in the registry — exactly the part I needed for a temp/humidity board. As a user the failure is undebuggable: search says the package exists, the site shows it, and bun's "tag not found, but package exists" gives no hint that the published release simply has no artifact. Either hiding release-less packages from search, showing a "no installable release" banner on the package page, or having the proxy return 404 (instead of a dist-tag pointing at nothing) would all make this a much clearer dead end — or better, a rebuild path so the release becomes installable.
Description
The registry npm proxy advertises a
latestdist-tag for@tsci/x4132.sht40_ad1b_r2but serves an emptyversionsmap, so the package can be found but never installed.Steps to reproduce
x4132/SHT40_AD1B_R2comes back (package search API, and it has a normal package page).bun add @tsci/x4132.SHT40_AD1B_R2(or the lowercase name) in any project → the error above.curl https://npm.tscircuit.com/@tsci%2fx4132.sht40_ad1b_r2shows the inconsistency directly:{"name":"@tsci/x4132.sht40_ad1b_r2","dist-tags":{"latest":"0.1.0"}, ..., "versions":{}}The registry API itself knows the release:
package_releases/listreturns version 0.1.0 created 2025-08-26, same timestamp as the package. So this isn't a package that was never published — the release exists but the npm proxy has nothing installable for it (possibly a build/transpile that never completed;has_transpiled_codeis null on the release).Why it hurts
This was the only SHT40 sensor package in the registry — exactly the part I needed for a temp/humidity board. As a user the failure is undebuggable: search says the package exists, the site shows it, and bun's "tag not found, but package exists" gives no hint that the published release simply has no artifact. Either hiding release-less packages from search, showing a "no installable release" banner on the package page, or having the proxy return 404 (instead of a dist-tag pointing at nothing) would all make this a much clearer dead end — or better, a rebuild path so the release becomes installable.