This repo committed BOTH package-lock.json and pnpm-lock.yaml — two descriptions of
one dependency tree, neither reconciled against the other. CI then ran
`npm ci || npm install`, which is the shape that lets that persist: when the lockfile
stops matching package.json, the fallback silently resolves a different tree and the
run still goes green. A lockfile nobody fails on is not a lockfile.
Now there is one. pnpm-lock.yaml is tracked, package-lock.json is deleted and
ignored along with every other manager's, corepack takes the pnpm version from
`packageManager`, and Docker and CI both install with --frozen-lockfile so a drifted
tree stops the build instead of being papered over.
The `pnpm.onlyBuiltDependencies` field in package.json was dead — pnpm 11 reads
settings from pnpm-workspace.yaml and prints a warning that it ignored it. Its five
entries moved there verbatim, documented, so the build-script denial is actually in
effect rather than merely written down.
esbuild goes ^0.27.4 -> ^0.28.1, the version console already builds with. 0.27.4's
install script overwrites its own bin/esbuild with a raw ELF, and pnpm's shim reads
a missing shebang as "run this with node", so `pnpm build` died on
`SyntaxError: Invalid or unexpected token` at the first byte. Same minor series, and
it is what makes the build work under pnpm at all.
Verified: frozen-lockfile install clean, `pnpm build` emits a 617KB bundle, 354
tests passing.
Co-authored-by: Hanzo Dev <[email protected]>
Adopt the canonical Hanzo Node base image. Node 24 uniform across the
fleet; sqlite3 bundled (node:sqlite builtin + native better-sqlite3
toolchain). One base, one way.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev