standardize every Node-based Dockerfile in ~/ on FROM node:24-alpine AND #15

New Issue

brendan · 2026-05-13T19:01:58Z

brendan commented

2026-05-13 19:01:58 +00:00

Originally filed: 2026-05-12 in ~/features.md, block #1.
Cross-project companion issues: brendan/authd, brendan/buchinese, brendan/dashcam, brendan/inventory, brendan/movement

2026-05-12 — fleet chore: standardize every Node-based Dockerfile in ~/ on FROM node:24-alpine AND apk add --no-cache … git so the build image can resolve npm git+https:// dependencies and so we stop tripping npm 10.9's EBADPLATFORM trap on nested platform-specific optional deps

Motivation. Over the last 24 hours four projects (authd, buchinese, nanodrop, inventory) shipped a sqlite-migrate adoption PR and four deploys went red on the same root cause: their node:*-alpine build image doesn't ship git, so npm ci couldn't resolve bchen-sqlite-migrate@git+https://gitea.bchen.dev/brendan/sqlite-migrate.git#v0.1.0 and printed a misleading "tarball … seems to be corrupted" warning before exiting with ENOENT spawn git. The fixes have been (or are being) applied one-by-one as bugs surface — authd PR #16 (git added, base already on 24), nanodrop PR #10 (bumped to 24 + git added), buchinese pending, inventory pending. dashcam and movement haven't tripped the bug yet because they don't currently consume any git+https:// dep, but they have the same latent vulnerability and will fire the next time any of them adopts sqlite-migrate or any other private-Gitea-URL dep.

Separately, the node:22-alpine base ships npm 10.9, which has a documented bug where nested @esbuild/* platform-specific optional deps (introduced by e.g. vitest 4.x) are misclassified as required and cause EBADPLATFORM for @esbuild/aix-ppc64 on linux/x64 builds. authd already documented this and bumped to node:24-alpine (npm 11.x); buchinese is currently tripping the bug for real.

Current state (snapshot 2026-05-12 after git fetch against origin/main for each project; verified via ~/<repo>/Dockerfile):

project	base image	apk install line	has `git`?	consumes `git+https://`?
authd	`node:24-alpine`	`apk add --no-cache python3 make g++ git`	YES (post PR #16)	YES (bchen-sqlite-migrate)
buchinese	`node:22-alpine`	`apk add --no-cache python3 make g++`	NO	YES (bchen-sqlite-migrate)
inventory	`node:22-alpine`	`apk add --no-cache python3 make g++`	NO	YES (bchen-sqlite-migrate)
nanodrop	`node:24-alpine`	`apk add --no-cache python3 make g++ git`	YES (post PR #10)	YES (bchen-sqlite-migrate)
dashcam	`node:22-alpine`	`apk add --no-cache ffmpeg python3 make g++`	NO	NO
movement	`node:20-alpine`	`apk add --no-cache python3 make g++`	NO	NO

Scope. Bring every project in the table to the canonical shape: FROM node:24-alpine plus git appended to its existing apk install line (preserving any project-specific extras like dashcam's ffmpeg). Six PRs, one per project. Four of them (buchinese, inventory, dashcam, movement) actually need changes; two (authd, nanodrop) already match the target — implementer should verify and skip-with-note rather than ship a no-op PR.

For each project requiring a change:

Edit the Dockerfile (~/<repo>/Dockerfile:1 and the RUN apk add line — typically line 3 or 4). Two-line diff: bump base if it's not already node:24-alpine, append git to the apk install if it's not there. Preserve project-specific apk extras (dashcam: ffmpeg; future projects may add imagemagick, curl, etc.).
Verify locally before push:
- npm ci against a clean node_modules succeeds.
- tsc --noEmit clean.
- npm run build (if a build step exists) clean.
- Project-specific test suite (npm test or vitest run) green.
  No expected behavior changes; the diff is build-environment-only, so test-count-delta should be zero.
docker build . can't be exercised inside the sandbox (no docker daemon socket reachable, same caveat as the existing sqlite-migrate-adoption PRs). Deferred to the first prod deploy on the new image.
Open the PR using the per-project worktree pattern (per ~/roles/_sub-claude-rules.md): branch chore/dockerfile-node24-and-git, single chore: commit, auto-merge via the Gitea sync-from-main precondition. Refactor pass: noop on a two-line diff. Security pass: zero in scope (build-time dependency change; the runtime image gains git but no application code uses child_process/spawn/exec to invoke it on user input, so the footgun is purely "if you already have RCE you also have git").

Dependency-compatibility audit (so implementer doesn't have to redo it per project): every project in the table runs the same general TypeScript/Node stack — better-sqlite3, fastify, tsx, vitest — and authd's PR #15/#16 confirmed all of them ship node-24 prebuilds (better-sqlite3@12.6.2, bcrypt@6.0.0, fastify@5.7.4, tsx@4.21.0, vitest@4.0.18). nanodrop PR #10 reconfirmed the same. movement is currently on node:20-alpine (oldest in the fleet) — its better-sqlite3 and other native deps may need to be bumped to node-24-compatible versions; if npm ci after the base bump fails on a native-dep prebuild, ABANDON for movement specifically and re-file as a movement-only sub-item so the dep bumps can be handled separately. The other four are guaranteed-compatible per the prior PRs.

Acceptance.

Every Node-based Dockerfile in ~/ reads FROM node:24-alpine AND its RUN apk add line includes git.
For each project, the next deploy CI run on main (re-run of latest, or fresh trivial commit) reaches success. No EBADPLATFORM, no "tarball … seems to be corrupted", no ENOENT spawn git.
npm ci resolution of any future git+https:// dep works fleet-wide without per-project Dockerfile patching.
No application behavior changes; each project's test suite green delta is 0.
Two pending bugs in ~/bugs.md (buchinese, inventory — both filed 2026-05-12) become moot once this chore lands; bug-fixer should ABANDON them with a note pointing at the chore's merge commits.

Future-projects rule. A standing rule has been added to ~/.claude/CLAUDE.md ("Node + Alpine Docker base images — node:24-alpine + git") so every new Node-based project the user (or any Claude session) bootstraps starts with the canonical Dockerfile shape. That rule lives next to the existing iOS-16px-font-size standing rule — same template (file a retrofit chore for current fleet, then add a standing rule to prevent regression for everything new).

Filer notes.

This chore exists primarily to stop re-discovering the same root cause one project at a time. If the implementer ships it before the buchinese + inventory bugs are picked up by the bug-fixer, those bugs convert to no-ops — file resolution notes against them.
Recommended PR ordering: buchinese first (currently red, highest user-visible value), inventory second (also red), dashcam third (not failing today but ships ffmpeg — verify the apk add line preservation), movement last (oldest base, riskiest dep audit). authd and nanodrop are no-ops.

> **Originally filed:** 2026-05-12 in ~/features.md, block #1. > **Cross-project companion issues:** brendan/authd, brendan/buchinese, brendan/dashcam, brendan/inventory, brendan/movement **2026-05-12 — fleet chore: standardize every Node-based `Dockerfile` in `~/` on `FROM node:24-alpine` AND `apk add --no-cache … git` so the build image can resolve `npm` `git+https://` dependencies and so we stop tripping npm 10.9's EBADPLATFORM trap on nested platform-specific optional deps**  **Motivation.** Over the last 24 hours four projects (authd, buchinese, nanodrop, inventory) shipped a sqlite-migrate adoption PR and four deploys went red on the same root cause: their `node:*-alpine` build image doesn't ship `git`, so `npm ci` couldn't resolve `bchen-sqlite-migrate@git+https://gitea.bchen.dev/brendan/sqlite-migrate.git#v0.1.0` and printed a misleading "tarball … seems to be corrupted" warning before exiting with `ENOENT spawn git`. The fixes have been (or are being) applied one-by-one as bugs surface — authd PR #16 (`git` added, base already on 24), nanodrop PR #10 (bumped to 24 + `git` added), buchinese pending, inventory pending. dashcam and movement haven't tripped the bug yet because they don't currently consume any `git+https://` dep, but they have the same latent vulnerability and will fire the next time any of them adopts sqlite-migrate or any other private-Gitea-URL dep. Separately, the `node:22-alpine` base ships npm 10.9, which has a documented bug where nested `@esbuild/*` platform-specific optional deps (introduced by e.g. vitest 4.x) are misclassified as required and cause `EBADPLATFORM` for `@esbuild/aix-ppc64` on linux/x64 builds. authd already documented this and bumped to `node:24-alpine` (npm 11.x); buchinese is currently tripping the bug for real. **Current state** (snapshot 2026-05-12 after `git fetch` against `origin/main` for each project; verified via `~/<repo>/Dockerfile`): | project | base image | apk install line | has `git`? | consumes `git+https://`? | |---|---|---|---|---| | authd | `node:24-alpine` | `apk add --no-cache python3 make g++ git` | YES (post PR #16) | YES (bchen-sqlite-migrate) | | buchinese | `node:22-alpine` | `apk add --no-cache python3 make g++` | NO | YES (bchen-sqlite-migrate) | | inventory | `node:22-alpine` | `apk add --no-cache python3 make g++` | NO | YES (bchen-sqlite-migrate) | | nanodrop | `node:24-alpine` | `apk add --no-cache python3 make g++ git` | YES (post PR #10) | YES (bchen-sqlite-migrate) | | dashcam | `node:22-alpine` | `apk add --no-cache ffmpeg python3 make g++` | NO | NO | | movement | `node:20-alpine` | `apk add --no-cache python3 make g++` | NO | NO | **Scope.** Bring every project in the table to the canonical shape: `FROM node:24-alpine` plus `git` appended to its existing apk install line (preserving any project-specific extras like dashcam's `ffmpeg`). Six PRs, one per project. Four of them (buchinese, inventory, dashcam, movement) actually need changes; two (authd, nanodrop) already match the target — implementer should verify and skip-with-note rather than ship a no-op PR. For each project requiring a change: 1. Edit the Dockerfile (`~/<repo>/Dockerfile:1` and the `RUN apk add` line — typically line 3 or 4). Two-line diff: bump base if it's not already `node:24-alpine`, append `git` to the apk install if it's not there. Preserve project-specific apk extras (dashcam: `ffmpeg`; future projects may add `imagemagick`, `curl`, etc.). 2. Verify locally before push: - `npm ci` against a clean `node_modules` succeeds. - `tsc --noEmit` clean. - `npm run build` (if a build step exists) clean. - Project-specific test suite (`npm test` or `vitest run`) green. No expected behavior changes; the diff is build-environment-only, so test-count-delta should be zero. 3. `docker build .` can't be exercised inside the sandbox (no docker daemon socket reachable, same caveat as the existing sqlite-migrate-adoption PRs). Deferred to the first prod deploy on the new image. 4. **Open the PR using the per-project worktree pattern** (per `~/roles/_sub-claude-rules.md`): branch `chore/dockerfile-node24-and-git`, single `chore:` commit, auto-merge via the Gitea sync-from-main precondition. Refactor pass: noop on a two-line diff. Security pass: zero in scope (build-time dependency change; the runtime image gains `git` but no application code uses `child_process`/`spawn`/`exec` to invoke it on user input, so the footgun is purely "if you already have RCE you also have git"). **Dependency-compatibility audit** (so implementer doesn't have to redo it per project): every project in the table runs the same general TypeScript/Node stack — `better-sqlite3`, `fastify`, `tsx`, `vitest` — and authd's PR #15/#16 confirmed all of them ship node-24 prebuilds (`better-sqlite3@12.6.2`, `bcrypt@6.0.0`, `fastify@5.7.4`, `tsx@4.21.0`, `vitest@4.0.18`). nanodrop PR #10 reconfirmed the same. movement is currently on `node:20-alpine` (oldest in the fleet) — its `better-sqlite3` and other native deps may need to be bumped to node-24-compatible versions; if `npm ci` after the base bump fails on a native-dep prebuild, **ABANDON for movement specifically** and re-file as a movement-only sub-item so the dep bumps can be handled separately. The other four are guaranteed-compatible per the prior PRs. **Acceptance.** - Every Node-based `Dockerfile` in `~/` reads `FROM node:24-alpine` AND its `RUN apk add` line includes `git`. - For each project, the next deploy CI run on `main` (re-run of latest, or fresh trivial commit) reaches `success`. No `EBADPLATFORM`, no "tarball … seems to be corrupted", no `ENOENT spawn git`. - `npm ci` resolution of any future `git+https://` dep works fleet-wide without per-project Dockerfile patching. - No application behavior changes; each project's test suite green delta is 0. - Two pending bugs in `~/bugs.md` (buchinese, inventory — both filed 2026-05-12) become moot once this chore lands; bug-fixer should ABANDON them with a note pointing at the chore's merge commits. **Future-projects rule.** A standing rule has been added to `~/.claude/CLAUDE.md` ("Node + Alpine Docker base images — `node:24-alpine` + `git`") so every new Node-based project the user (or any Claude session) bootstraps starts with the canonical Dockerfile shape. That rule lives next to the existing iOS-16px-font-size standing rule — same template (file a retrofit chore for current fleet, then add a standing rule to prevent regression for everything new). **Filer notes.** - This chore exists primarily to stop re-discovering the same root cause one project at a time. If the implementer ships it before the buchinese + inventory bugs are picked up by the bug-fixer, those bugs convert to no-ops — file resolution notes against them. - Recommended PR ordering: buchinese first (currently red, highest user-visible value), inventory second (also red), dashcam third (not failing today but ships `ffmpeg` — verify the `apk add` line preservation), movement last (oldest base, riskiest dep audit). authd and nanodrop are no-ops.

brendan added the feature label 2026-05-13 19:01:58 +00:00

brendan closed this issue

2026-05-13 19:01:58 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: brendan/nanodrop#15

standardize every Node-based Dockerfile in ~/ on FROM node:24-alpine AND #15

standardize every Node-based `Dockerfile` in `~/` on `FROM node:24-alpine` AND #15