#61

Fetching `next-auth` from npm fails with "error decoding response body"

OpenSteel-techopened 5mo ago

Summary

opensrc path next-auth and opensrc fetch next-auth both fail with Error: error decoding response body. Other Auth.js packages from the same repo work fine, and much larger npm-registry responses also work — so this looks like a structural issue with next-auth's package metadata that opensrc's deserializer rejects, not a size/network problem.

Repro

$ opensrc --version
opensrc 0.7.2

$ opensrc path next-auth
Error: error decoding response body

$ opensrc fetch next-auth
Fetching next-auth from npm...
  ✗ next-auth: error decoding response body
Error: Some sources could not be fetched

$ opensrc path next-auth@5.0.0-beta.31
Error: error decoding response body

Pinning the version doesn't help, which is consistent with the failure happening while decoding the package-level metadata (not a specific version's payload).

Counterexamples — these all work

Sibling packages in the same monorepo:

$ opensrc path @auth/core            # → .../nextauthjs/next-auth/0.41.2
$ opensrc path @auth/prisma-adapter  # → .../nextauthjs/next-auth/2.11.2

Much larger npm-registry responses:

PackageRegistry responseResult
next-auth3.6 MB❌ fails
zod3.5 MB✅ works
react6.6 MB✅ works
typescript15.4 MB✅ works
prisma43.2 MB✅ works

So size/bandwidth/memory is not the cause.

What's distinctive about next-auth's registry metadata

(Maybe useful as a starting point — curl -s https://registry.npmjs.org/next-auth | jq shows it; numbers as of filing.)

  • 725 published versions
  • 6 dist-tags: latest, beta, next, canary, experimental, next-auth-3
  • Mix of deprecated and non-deprecated versions
  • Long history going back to next-auth v1, then next-auth v3, plus current v4 stable and v5 beta in parallel

npm view next-auth versions decodes the same response without issue, so the JSON is valid — the failure is opensrc's deserializer being stricter than the response shape allows somewhere.

Workaround (for anyone hitting this)

Any sibling @auth/* package fetches the full monorepo, and the next-auth source lives at packages/next-auth/ inside it. The version inside the monorepo matches the latest published next-auth:

$ opensrc path @auth/prisma-adapter
$ cat "$(opensrc path @auth/prisma-adapter)/packages/next-auth/package.json" | jq .version
"5.0.0-beta.31"

Environment

  • opensrc 0.7.2 (installed via npm install -g opensrc)
  • macOS (Darwin 24.6.0)
  • Node v24.12.0

Note

Once PR #56's structured error handling lands in a release, the bare error decoding response body should presumably become a more specific message — which would make diagnosing this much easier.

Activity

1
TheAsda4mo ago

The same issue with opensrc path @tanstack/react-form