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 bodyPinning 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.2Much larger npm-registry responses:
| Package | Registry response | Result |
|---|---|---|
next-auth | 3.6 MB | ❌ fails |
zod | 3.5 MB | ✅ works |
react | 6.6 MB | ✅ works |
typescript | 15.4 MB | ✅ works |
prisma | 43.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-authv1, thennext-authv3, 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 vianpm 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.
The same issue with
opensrc path @tanstack/react-form