@rindle/cli — the Rindle toolchain, prebuilt for npm

The Rindle CLI (rindle) and daemon (rindled), shipped as prebuilt, per-platform binaries you can npm install. This is how a JS/TS developer runs Rindle locally:

• rindled — the production Rindle server: the rindle-server crate (the SQLite-backed rindle-replica live-query engine plus the public subscription/lease plane).
• rindle — the CLI to inspect, run, and manage a daemon: rindle status / migrate / schema, plus the local-dev pair rindle init (scaffold) and rindle up (run-and-supervise a local rindled, respawning it on crash or migrate-restart).

This is the network counterpart of @rindle/replica: both run the same rindle-replica engine, but @rindle/replica is a napi addon that embeds it in-process, whereas rindled is the standalone daemon executable that serves many clients over the wire. Talk to a running daemon from JS with @rindle/daemon-client.

npm i -D @rindle/cli
npx rindle init      # scaffold daemon.json + migrations/
npx rindle up --migrate --gen shared/schema.gen.ts --watch
# start + supervise rindled, apply migrations, regenerate the typed schema,
# and re-run apply/gen whenever migrations/ changes

Installing pulls in exactly one prebuilt-binary package for your platform via optionalDependencies (the esbuild/napi pattern) — nothing is compiled, and the other platforms' binaries are never downloaded.

Docs

Full docs — the command reference, flags & env vars, the local dev loop, and remote-daemon usage: rindle.sh/docs/rindle-cli · markdown mirror: rindle-cli.md · for agents: llms.txt

Embedding the daemon in your own supervisor

rindled is not exposed as a CLI command here — rindle up is the way to run a local daemon. The binary still ships (co-located with rindle), so for embedding it in your own Node supervisor there are programmatic helpers:

import { spawnRindled, rindledBinaryPath } from "@rindle/cli";

const child = spawnRindled(["--config", "./daemon.json"]); // inherits stdio
// …or just locate the binary and manage the process yourself:
const bin = rindledBinaryPath();

Running the daemon directly under an external supervisor (systemd / Docker / k8s) in production is a job for the cargo-dist installers or a container image, not npm.

How the packaging works

• @rindle/cli (this package) is a tiny, dependency-free launcher. Its bin/rindle (dist/cli.js) resolves the matching rindle binary for the host and execs it, forwarding argv/stdio and the exit code.
• @rindle/cli-<key> — one package per target (darwin-arm64, darwin-x64, linux-x64-gnu, linux-arm64-gnu, linux-x64-musl, linux-arm64-musl, win32-x64-msvc), each carrying both rindle and rindled for that platform under bin/, gated by os/cpu/libc. They're listed as optionalDependencies of this package, so the installer fetches only the matching one. They are generated at release time (like the napi platform packages for @rindle/replica), never committed.

Both binaries ship co-located on purpose: even though only rindle is a bin, rindle up runs rindled by finding it as a sibling of its own executable (rindle-cli §7.1), so the two must live in the same bin/ directory.

Resolution order at runtime (src/index.ts):

1. RINDLE_BINARY_PATH / RINDLED_BINARY_PATH — explicit path to that one binary.
2. RINDLE_BIN_DIR — a directory holding both (see dev usage below).
3. the installed @rindle/cli-<key> optional dependency.

Local development (in this monorepo)

No platform packages are installed in the workspace, so build the binaries and point the launcher at the build directory — one env var lights up both (and keeps them co-located for rindle up):

cargo build -p rindle-cli -p rindle-server --bin rindle --bin rindled --release
RINDLE_BIN_DIR="$PWD/target/release" npx rindle up      # finds rindled in the same dir
RINDLE_BIN_DIR="$PWD/target/release" npx rindle status

(Or set RINDLE_BINARY_PATH / RINDLED_BINARY_PATH to point at one binary each — e.g. RINDLED_BINARY_PATH is what spawnRindled() / rindledBinaryPath() resolve in dev.)

Releasing

The native binaries already come from dist (cargo-dist): rindle-cli and rindle-server are both [package.metadata.dist] dist = true, so dist builds rindle and rindled for all four targets and uploads the archives + dist-manifest.json to a GitHub release. scripts/build-npm-packages.mjs is the bridge from those artifacts to npm:

# from a published release (reads its dist-manifest.json — no archive-name guessing):
node scripts/build-npm-packages.mjs --from-release rindle-cli-v0.1.0 --update-root

# …or from locally available binaries laid out as <dir>/<rust-target>/<bin>[.exe]:
node scripts/build-npm-packages.mjs --bin-dir ./bins --version 0.1.0 --update-root

--update-root writes this package's version + optionalDependencies in lockstep. Then publish each npm/<key> package, then the umbrella. (The binaries + targets live in package.json under "rindle", the single source of truth shared by the generator and the runtime resolver.)