Dockerfile uses `npm install` but project declares `workspace:*` deps (pnpm-only) #1

New issue

Closed

opened 2026-05-25 21:51:24 +00:00 by padreug · 0 comments

padreug commented

2026-05-25 21:51:24 +00:00

Owner

Symptom

A clean clone of upstream kind-0/nsecbunkerd at HEAD fails to build with:

npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:*

…on RUN npm install in the upstream Dockerfile. The build never completes; no Docker Hub image can be produced this way.

Root cause

package.json declares "@nostr-dev-kit/ndk": "workspace:*" (and possibly other workspace refs). The workspace: protocol is a pnpm feature (also yarn berry); npm has no concept of it. The repo ships a pnpm-lock.yaml (no package-lock.json), confirming the intended package manager is pnpm.

The upstream Dockerfile's RUN npm install therefore can't work on any clean clone — it would only succeed in an environment where npm somehow already had the workspace resolution figured out, which isn't possible without monkey-patching.

Fix we applied (in `aiolabs/nsecbunkerd`)

Switch the Dockerfile to pnpm. Patched in ~/dev/local/docker/regtest/nsecbunker/Dockerfile (local build context):

FROM node:20.11-bullseye AS build
WORKDIR /app
RUN npm install -g pnpm@9
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --no-frozen-lockfile
COPY . .
RUN npx prisma generate
RUN pnpm run build

FROM node:20.11-alpine AS runtime
WORKDIR /app
RUN apk update && apk add --no-cache openssl && rm -rf /var/cache/apk/*
RUN npm install -g pnpm@9
COPY --from=build /app .
RUN pnpm install --prod --no-frozen-lockfile

EXPOSE 3000
ENTRYPOINT [ "node", "./dist/index.js" ]
CMD ["start"]

(--no-frozen-lockfile is required for a separate reason — see #2.)

Upstream impact

Cannot be using vanilla upstream without local patches. Has been in this state on kind-0/nsecbunkerd for at least the last major commits we examined. Likely Pablo's own deploy pipeline uses pnpm directly and the Dockerfile drifted.

Acceptance for this issue (in our fork)

Local Dockerfile patched to use pnpm (in our deploy's build context).
Filed upstream at kind-0/nsecbunkerd#?.

Cross-refs

Discovered during phase 2 of aiolabs/lnbits#9 (aiolabs/lnbits#18).
Companion issues: #2 (frozen-lockfile), #3 (workspace:* resolution), #4 (pingOrDie), #5 (getKeys type bug), #6 (Docker Hub platform).

## Symptom A clean clone of upstream `kind-0/nsecbunkerd` at HEAD fails to build with: ``` npm ERR! code EUNSUPPORTEDPROTOCOL npm ERR! Unsupported URL Type "workspace:": workspace:* ``` …on `RUN npm install` in the upstream `Dockerfile`. The build never completes; no Docker Hub image can be produced this way. ## Root cause `package.json` declares `"@nostr-dev-kit/ndk": "workspace:*"` (and possibly other workspace refs). The `workspace:` protocol is a **pnpm** feature (also yarn berry); npm has no concept of it. The repo ships a `pnpm-lock.yaml` (no `package-lock.json`), confirming the intended package manager is pnpm. The upstream Dockerfile's `RUN npm install` therefore can't work on any clean clone — it would only succeed in an environment where npm somehow already had the workspace resolution figured out, which isn't possible without monkey-patching. ## Fix we applied (in `aiolabs/nsecbunkerd`) Switch the Dockerfile to pnpm. Patched in `~/dev/local/docker/regtest/nsecbunker/Dockerfile` (local build context): ```dockerfile FROM node:20.11-bullseye AS build WORKDIR /app RUN npm install -g pnpm@9 COPY package.json pnpm-lock.yaml ./ RUN pnpm install --no-frozen-lockfile COPY . . RUN npx prisma generate RUN pnpm run build FROM node:20.11-alpine AS runtime WORKDIR /app RUN apk update && apk add --no-cache openssl && rm -rf /var/cache/apk/* RUN npm install -g pnpm@9 COPY --from=build /app . RUN pnpm install --prod --no-frozen-lockfile EXPOSE 3000 ENTRYPOINT [ "node", "./dist/index.js" ] CMD ["start"] ``` (`--no-frozen-lockfile` is required for a separate reason — see #2.) ## Upstream impact Cannot be using vanilla upstream without local patches. Has been in this state on `kind-0/nsecbunkerd` for at least the last major commits we examined. Likely Pablo's own deploy pipeline uses pnpm directly and the Dockerfile drifted. ## Acceptance for this issue (in our fork) - [x] Local Dockerfile patched to use pnpm (in our deploy's build context). - [ ] Filed upstream at `kind-0/nsecbunkerd#?`. ## Cross-refs - Discovered during phase 2 of `aiolabs/lnbits#9` (`aiolabs/lnbits#18`). - Companion issues: #2 (frozen-lockfile), #3 (workspace:* resolution), #4 (pingOrDie), #5 (getKeys type bug), #6 (Docker Hub platform).

padreug referenced this issue

2026-05-25 21:51:39 +00:00

pnpm-lock.yaml is out of date vs package.json — frozen install fails #2

padreug referenced this issue

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

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

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:56:06 +00:00

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