Caught live, deployed to the actual target -- the previous version
failed on the real host with "Cannot use import statement outside a
module" (Node 18, no ancestor package.json to signal ESM for an
extensionless file). That surfaced two stacked bugs my own testing had
missed by running the bundle from inside this repo's own directory
tree, which coincidentally supplied both things the standalone
artifact was silently depending on:
1. Module-format ambiguity: an extensionless file with no controlling
package.json defaults to CommonJS on older Node (no auto-detection
heuristic before recent versions). Fixed by naming the bundle
output keep.mjs -- unconditionally ESM on any Node version,
regardless of extension-less-file heuristics or nearby package.json.
2. The bigger one: crypto.ts's createRequire(import.meta.url) trick
(needed because libsodium-wrappers' published ESM build follows a
broken relative import) is opaque to esbuild's static bundler --
it's a runtime-obtained require reference, not the literal `require`
token esbuild's bundling recognizes. The previous "18kb bundle"
never actually contained libsodium-wrappers at all; it silently
relied on real node_modules being nearby on disk, which was only
ever true by accident when testing from within this repo. On a
clean host it threw "Cannot find module 'libsodium-wrappers'".
Tried forcing static inlining via a literal require() call (esbuild
does special-case that even in ESM-format output, unlike `import`,
which is permanently pinned to the "import" resolution condition
and can't be routed to the package's working CJS build no matter
what --conditions/--main-fields/--alias combination is tried this
was tried and confirmed exhaustively). That got real resolution and
a real 1.7MB bundle, but broke at runtime with "No secure random
number generator found" -- inlining the WASM engine breaks its own
Node-crypto feature detection.
Landed on: ship libsodium-wrappers (and its own dependency,
libsodium) as real, unmodified package files alongside the ~18kb
bundle, via a new copy-cli-deps.mjs step, rather than fighting
further to force single-file inlining. ~1.6MB total, still one tar
stream over SSH, still the entire deploy step.
deploy-cli.sh now tars dist-bundle/ (bundle + node_modules) instead of
catting a single file, extracts to ~/.keep-cli/ on the target, and
symlinks ~/bin/keep to the entry point inside it.
Verified this time in conditions that actually match the failure: full
isolation (mktemp'd HOME and install dir, no ancestor package.json, no
adjacent node_modules from this repo) for both `node keep.mjs` and
direct shebang execution, plus the exact tar/extract cycle
deploy-cli.sh performs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
npm run cli -- <args> only works from inside this repo's directory,
which is awkward everywhere but especially on a deploy host running
this alongside a dozen other projects. scripts/install-cli.sh builds
the CLI and symlinks dist/cli/index.js onto PATH (~/.local/bin by
default, no root/global npm install needed) as a real `keep` command,
runnable from anywhere.
Symlinked rather than copied, so a future `git pull && npm run build`
is the entire upgrade story -- no need to re-run the install script
after the first time.
Verified: keep --help and keep identity show both work correctly from
unrelated directories (/tmp, $HOME) after running the install script,
confirming no hidden cwd dependency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SETUP.local.md.example is a fill-in-the-blanks runbook for rolling
keep out across real machines and projects (gitignored once copied to
SETUP.local.md — real vault keys/recipient ids/hostnames are fleet
topology, not something to commit). bootstrap-project.sh wraps push +
grant --read-only for one or more recipients into a single call for
onboarding a new project vault.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
keep overview gives an admin a cross-vault view of every recipient and
grant in one screen, instead of walking vaults one at a time via
/vaults/:key/recipients. scripts/deploy.sh pulls a project's env from
keep before running docker compose up, for VPS deploys of several
docker-compose projects.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
