`@nostr-dev-kit/ndk` declared as `workspace:*` with no workspace setup #3

New issue

Closed

opened 2026-05-25 21:52:01 +00:00 by padreug · 0 comments

padreug commented

2026-05-25 21:52:01 +00:00

Owner

Symptom

After patching the Dockerfile to use pnpm (per #1) and --no-frozen-lockfile (per #2), pnpm install --no-frozen-lockfile still fails:

ERR_PNPM_WORKSPACE_PKG_NOT_FOUND  In : "@nostr-dev-kit/ndk@workspace:*"
is in the dependencies but no package named "@nostr-dev-kit/ndk" is
present in the workspace

Packages found in the workspace:

(The empty "Packages found in the workspace:" line is the giveaway — pnpm scanned for workspace packages and found none.)

Root cause

package.json declares:

"@nostr-dev-kit/ndk": "workspace:*",

…but the repo has no pnpm-workspace.yaml and no sibling packages with the name @nostr-dev-kit/ndk. The workspace: protocol assumes a monorepo setup where the referenced package is another workspace member — there isn't one.

This means upstream is either:

(a) Developed inside a larger monorepo that does have NDK as a sibling (and the public repo is a partial export that doesn't carry the workspace config), or
(b) Just broken at HEAD.

The pnpm-lock.yaml confirms the resolved version was @nostr-dev-kit/ndk@2.8.1, so they were getting real NDK from npm at lockfile-generation time, not from a local workspace.

Fix we applied

Replace the workspace reference with a concrete version pin in package.json:

-    "@nostr-dev-kit/ndk": "workspace:*",
+    "@nostr-dev-kit/ndk": "2.8.1",

Version pulled from what the existing pnpm-lock.yaml was resolving ('@nostr-dev-kit/ndk':@nostr-dev-kit/ndk@2.8.1(typescript@5.1.3)).

Real fix

Either:

Replace workspace:* with "^2.8.1" (or whatever the intended pin is) — matches what the lockfile already resolves to.
Add a pnpm-workspace.yaml and vendor NDK in a sibling directory (probably not the intent).

Option 1 is the obvious one.

Acceptance

Local package.json pinned to 2.8.1.
Upstream package.json pin restored (whatever version).
Regenerate pnpm-lock.yaml post-pin (re-resolves #2).

Cross-refs

#1 (Dockerfile npm→pnpm) — prerequisite for hitting this issue.
#2 (lockfile drift) — same upstream maintenance gap.

## Symptom After patching the Dockerfile to use pnpm (per #1) and `--no-frozen-lockfile` (per #2), `pnpm install --no-frozen-lockfile` *still* fails: ``` ERR_PNPM_WORKSPACE_PKG_NOT_FOUND In : "@nostr-dev-kit/ndk@workspace:*" is in the dependencies but no package named "@nostr-dev-kit/ndk" is present in the workspace Packages found in the workspace: ``` (The empty "Packages found in the workspace:" line is the giveaway — pnpm scanned for workspace packages and found *none*.) ## Root cause `package.json` declares: ```json "@nostr-dev-kit/ndk": "workspace:*", ``` …but the repo has **no `pnpm-workspace.yaml`** and no sibling packages with the name `@nostr-dev-kit/ndk`. The `workspace:` protocol assumes a monorepo setup where the referenced package is another workspace member — there isn't one. This means upstream is either: - (a) Developed inside a larger monorepo that does have NDK as a sibling (and the public repo is a partial export that doesn't carry the workspace config), or - (b) Just broken at HEAD. The `pnpm-lock.yaml` confirms the resolved version was `@nostr-dev-kit/ndk@2.8.1`, so they were getting real NDK from npm at lockfile-generation time, not from a local workspace. ## Fix we applied Replace the workspace reference with a concrete version pin in `package.json`: ```diff - "@nostr-dev-kit/ndk": "workspace:*", + "@nostr-dev-kit/ndk": "2.8.1", ``` Version pulled from what the existing `pnpm-lock.yaml` was resolving (`'@nostr-dev-kit/ndk':@nostr-dev-kit/ndk@2.8.1(typescript@5.1.3)`). ## Real fix Either: 1. Replace `workspace:*` with `"^2.8.1"` (or whatever the intended pin is) — matches what the lockfile already resolves to. 2. Add a `pnpm-workspace.yaml` and vendor NDK in a sibling directory (probably not the intent). Option 1 is the obvious one. ## Acceptance - [x] Local `package.json` pinned to `2.8.1`. - [ ] Upstream `package.json` pin restored (whatever version). - [ ] Regenerate `pnpm-lock.yaml` post-pin (re-resolves #2). ## Cross-refs - #1 (Dockerfile npm→pnpm) — prerequisite for hitting this issue. - #2 (lockfile drift) — same upstream maintenance gap.

padreug referenced this issue

2026-05-25 21:52:33 +00:00

pingOrDie self-watchdog false-positives → bunker exits every 30s on non-public relays #4

padreug referenced this issue

2026-05-25 21:55:14 +00:00

getKeys throws on passphrase-encrypted entries — nip19.decode({iv, data}) fails #5

padreug referenced this issue

2026-05-25 21:56:06 +00:00

Docker Hub image pablof7z/nsecbunkerd:latest is arm64-only — fails on amd64 hosts #6

padreug referenced this issue

2026-05-25 21:57:14 +00:00

Investigate NDK echo issue — RPC responses unreliably reach client subscriptions on custom relays #7