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

New issue

Open

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

padreug commented

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

Owner

Symptom

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

ERR_PNPM_OUTDATED_LOCKFILE  Cannot install with "frozen-lockfile" because
pnpm-lock.yaml is not up to date with <ROOT>/package.json

Note that in CI environments this setting is true by default.

Root cause

pnpm-lock.yaml ships in the repo but doesn't match package.json — somebody updated dependencies in package.json without re-running pnpm install to regenerate the lockfile, or the lockfile was generated from a different version of package.json than the one currently committed.

Fix we applied

Drop --frozen-lockfile in the Dockerfile and pass --no-frozen-lockfile. This lets pnpm resolve fresh and write a new lockfile, at the cost of giving up the deterministic-install guarantee.

RUN pnpm install --no-frozen-lockfile
# ... and the runtime stage:
RUN pnpm install --prod --no-frozen-lockfile

Real fix

Regenerate the lockfile in the repo: pnpm install locally + commit pnpm-lock.yaml. Then frozen-install will work again. Should be a part of CI to keep it from drifting.

Acceptance

Local Dockerfile uses --no-frozen-lockfile as a workaround.
pnpm-lock.yaml regenerated + committed (upstream).
CI step added to fail on lockfile drift (upstream).

Cross-refs

#1 (Dockerfile npm→pnpm) — prerequisite for hitting this issue.

## Symptom After patching the Dockerfile to use pnpm (per #1), `pnpm install --frozen-lockfile` fails: ``` ERR_PNPM_OUTDATED_LOCKFILE Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>/package.json Note that in CI environments this setting is true by default. ``` ## Root cause `pnpm-lock.yaml` ships in the repo but doesn't match `package.json` — somebody updated dependencies in `package.json` without re-running `pnpm install` to regenerate the lockfile, or the lockfile was generated from a different version of `package.json` than the one currently committed. ## Fix we applied Drop `--frozen-lockfile` in the Dockerfile and pass `--no-frozen-lockfile`. This lets pnpm resolve fresh and write a new lockfile, at the cost of giving up the deterministic-install guarantee. ```dockerfile RUN pnpm install --no-frozen-lockfile # ... and the runtime stage: RUN pnpm install --prod --no-frozen-lockfile ``` ## Real fix Regenerate the lockfile in the repo: `pnpm install` locally + commit `pnpm-lock.yaml`. Then frozen-install will work again. Should be a part of CI to keep it from drifting. ## Acceptance - [x] Local Dockerfile uses `--no-frozen-lockfile` as a workaround. - [ ] `pnpm-lock.yaml` regenerated + committed (upstream). - [ ] CI step added to fail on lockfile drift (upstream). ## Cross-refs - #1 (Dockerfile npm→pnpm) — prerequisite for hitting this issue.

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

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