aiolabs/nsecbunkerd
8
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

deps: refresh runtime deps to current stable (pnpm, prisma, nodejs, NDK, fastify, …) #19

New issue
Open
opened 2026-06-03 13:10:05 +00:00 by padreug · 0 comments
padreug commented 2026-06-03 13:10:05 +00:00
Owner
Copy link

Why

Recent build/deploy work (8ee0595 pnpm_8→9 nix fix; 131f689 prisma 5.4.1→6.19.3) exposed that the package's runtime is anchored to versions from when the repo was forked. Each subsequent fix has been the minimum nudge needed to get nix/Docker to build today, not a deliberate refresh. As a result we're carrying drift across the toolchain that's hard to reason about in aggregate.

This issue is the umbrella to refresh everything pinned to a stale floor in a single coordinated pass — so future bumps (NDK 4.x, new prisma engines split in nixpkgs, etc.) land against a clean baseline.

Current state (HEAD = 131f689 on dev)

Package Pinned Latest stable (2026-06-03) Notes
prisma / @prisma/client ^6.19.0 7.x bumped 131f689; nixpkgs unstable's prisma-engines_7 only ships schema-engine (no libquery_engine.node / query-engine bin), so 7.x not yet feasible in nix — track upstream nixpkgs fix
pnpm (Dockerfile + nix) 9.x (Dockerfile uses pnpm@9; nix pnpm_9 = 9.15.9) 11.5.1 lockfileVersion 9 stays readable; eyeball whether the bump to v10/v11 changes the lockfile shape and regen if so
nodejs (Dockerfile + nix) 20.x (LTS) Node 22 LTS Node 20 EOL is April 2026; bump to 22 to extend runway
@nostr-dev-kit/ndk 3.0.3 check NDK release feed NDK has ongoing breaking changes; whichever bump comes next, take it alongside nostr-tools
nostr-tools ~2.20.0 2.x latest constrained to ~2.20.0 by 14e8f24 / e8f245c (regtest Node 20 / curves v2 ESM-only); Node 22 bump above may unblock raising this
fastify ^4.24.3 5.x major; check route/plugin compat
@fastify/formbody ^7.4.0 8.x aligned with fastify-5
@fastify/view ^8.2.0 latest aligned with fastify-5
express ^4.18.2 5.x major; CVE backlog on 4.18.x worth flushing
axios ^1.6.2 1.x latest minor, security-only
bcrypt ^5.1.1 6.x major; node-gyp postinstall path has historically been fragile, validate
dotenv ^16.3.1 17.x trivial bump
tsup ^7.2.0 9.x dev-only; verify the tsup src/... invocations in package.json scripts.build still produce identical dist/
typescript ^5.1.3 5.x latest trivial
ts-node ^10.9.1 10.x latest trivial
@types/node ^18.16.18 22.x align with Node 22 bump
@inquirer/password / @inquirer/prompts ^1.x 7.x / 9.x inquirer rewrote prompts API multiple times; sweep CLI usage sites
eslint-config-prettier / eslint-plugin-import ^8.x / ^2.27.5 10.x / latest dev-only
lnbits, lnbits-ts ^1.1.5, ^0.0.2 unchanged aiolabs-owned; bump in lockstep with whatever the bunker actually calls into

Scope

  • One PR per "concern group", not one mega-bump (per workspace commit cadence):

    1. Toolchain — Node 20 → 22, pnpm 9 → 11 (nix + Dockerfile), nixpkgs prisma-engines revisit
    2. Database — when nixpkgs ships a usable prisma-engines_7, prisma 6 → 7
    3. Web server — fastify 4 → 5 + plugins, express 4 → 5
    4. Crypto / NDK — next NDK + nostr-tools bump (paired)
    5. Dev/build tooling — tsup, typescript, eslint, ts-node, types/node
    6. Trivial bumps — axios, dotenv, bcrypt, inquirer (each one a small PR if they need touching)

  • Each PR must:

    • Build under the nix package path (nix build .#nsecbunkerd from the repo)
    • Build under Docker (docker compose -f docker-compose.dev.yml build nsecbunker from ~/dev/local/docker/regtest/)
    • Pass the local regtest smoke (lnbits ↔ bunker create_new_key / unlock_key admin round-trip)
    • Update the pnpmDeps hash in package.nix in the same commit as the lockfile change

  • Schema is not to be modified as part of this work. Any prisma migrations land separately so this remains a deps-only refresh.

Out of scope

  • Lockfile cleanup unrelated to the bumps above (will surface naturally if needed)
  • Master-branch rebase strategy — handled separately once dev is stabilized

Context

This came up while wiring nsecbunkerd into server-deploy/hosts/demo for the aiolabs staging deploy. The deploy-side wiring is done (NixOS module + systemd unit + lnbits NIP-46 env vars on aio-demo) — this issue is so that next time anyone touches the bunker, the floor is fresh rather than each fix being reactive.

## Why Recent build/deploy work (`8ee0595` pnpm_8→9 nix fix; `131f689` prisma 5.4.1→6.19.3) exposed that the package's runtime is anchored to versions from when the repo was forked. Each subsequent fix has been the minimum nudge needed to get nix/Docker to build today, not a deliberate refresh. As a result we're carrying drift across the toolchain that's hard to reason about in aggregate. This issue is the umbrella to refresh everything pinned to a stale floor in a single coordinated pass — so future bumps (NDK 4.x, new prisma engines split in nixpkgs, etc.) land against a clean baseline. ## Current state (HEAD = `131f689` on `dev`) | Package | Pinned | Latest stable (2026-06-03) | Notes | |---|---|---|---| | `prisma` / `@prisma/client` | `^6.19.0` | 7.x | bumped 131f689; nixpkgs unstable's `prisma-engines_7` only ships `schema-engine` (no `libquery_engine.node` / `query-engine` bin), so 7.x not yet feasible in nix — track upstream nixpkgs fix | | `pnpm` (Dockerfile + nix) | 9.x (Dockerfile uses `pnpm@9`; nix `pnpm_9` = 9.15.9) | 11.5.1 | lockfileVersion 9 stays readable; eyeball whether the bump to v10/v11 changes the lockfile shape and regen if so | | `nodejs` (Dockerfile + nix) | 20.x (LTS) | Node 22 LTS | Node 20 EOL is April 2026; bump to 22 to extend runway | | `@nostr-dev-kit/ndk` | `3.0.3` | check NDK release feed | NDK has ongoing breaking changes; whichever bump comes next, take it alongside `nostr-tools` | | `nostr-tools` | `~2.20.0` | 2.x latest | constrained to ~2.20.0 by 14e8f24 / `e8f245c` (regtest Node 20 / curves v2 ESM-only); Node 22 bump above may unblock raising this | | `fastify` | `^4.24.3` | 5.x | major; check route/plugin compat | | `@fastify/formbody` | `^7.4.0` | 8.x | aligned with fastify-5 | | `@fastify/view` | `^8.2.0` | latest | aligned with fastify-5 | | `express` | `^4.18.2` | 5.x | major; CVE backlog on 4.18.x worth flushing | | `axios` | `^1.6.2` | 1.x latest | minor, security-only | | `bcrypt` | `^5.1.1` | 6.x | major; node-gyp postinstall path has historically been fragile, validate | | `dotenv` | `^16.3.1` | 17.x | trivial bump | | `tsup` | `^7.2.0` | 9.x | dev-only; verify the `tsup src/...` invocations in `package.json scripts.build` still produce identical dist/ | | `typescript` | `^5.1.3` | 5.x latest | trivial | | `ts-node` | `^10.9.1` | 10.x latest | trivial | | `@types/node` | `^18.16.18` | 22.x | align with Node 22 bump | | `@inquirer/password` / `@inquirer/prompts` | `^1.x` | 7.x / 9.x | inquirer rewrote prompts API multiple times; sweep CLI usage sites | | `eslint-config-prettier` / `eslint-plugin-import` | `^8.x` / `^2.27.5` | 10.x / latest | dev-only | | `lnbits`, `lnbits-ts` | `^1.1.5`, `^0.0.2` | unchanged | aiolabs-owned; bump in lockstep with whatever the bunker actually calls into | ## Scope - One PR per "concern group", not one mega-bump (per workspace commit cadence): 1. **Toolchain** — Node 20 → 22, pnpm 9 → 11 (nix + Dockerfile), nixpkgs `prisma-engines` revisit 2. **Database** — when nixpkgs ships a usable `prisma-engines_7`, prisma 6 → 7 3. **Web server** — fastify 4 → 5 + plugins, express 4 → 5 4. **Crypto / NDK** — next NDK + nostr-tools bump (paired) 5. **Dev/build tooling** — tsup, typescript, eslint, ts-node, types/node 6. **Trivial bumps** — axios, dotenv, bcrypt, inquirer (each one a small PR if they need touching) - Each PR must: - Build under the nix package path (`nix build .#nsecbunkerd` from the repo) - Build under Docker (`docker compose -f docker-compose.dev.yml build nsecbunker` from `~/dev/local/docker/regtest/`) - Pass the local regtest smoke (lnbits ↔ bunker create_new_key / unlock_key admin round-trip) - Update the `pnpmDeps` hash in `package.nix` in the same commit as the lockfile change - Schema is **not** to be modified as part of this work. Any prisma migrations land separately so this remains a deps-only refresh. ## Out of scope - Lockfile cleanup unrelated to the bumps above (will surface naturally if needed) - Master-branch rebase strategy — handled separately once dev is stabilized ## Context This came up while wiring nsecbunkerd into `server-deploy/hosts/demo` for the aiolabs staging deploy. The deploy-side wiring is done (NixOS module + systemd unit + lnbits NIP-46 env vars on aio-demo) — this issue is so that *next* time anyone touches the bunker, the floor is fresh rather than each fix being reactive.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
dev
docs-migration-runbook
issue-9-fix-create-new-key-race
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
aiolabs/nsecbunkerd#19
No description provided.