Sprint 10 in progress: desktop packaging (A1)

Sprint 10 is still open. This is a mid-sprint build-in-public checkpoint, not a closure post.

The desktop app is a Tauri shell over our existing TypeScript packages, with a Node sidecar doing the real work. That is fine in pnpm dev, but a shipped app has no monorepo around it. First packaging step (A1) is done.

Context: ADR-0010 Option A · Sprint 10 worklog · commit 6d36419.


What A1 delivered

  • Compiled sidecar under plain Nodebuild:sidecar output runs with bundled node from dist (no tsx). Verified: node sidecar/dist/run-server.js serves /health, and top-level imports of @meronq/{server-core,memory,scanner} resolve at startup.
  • Env-driven MCP entryresolveMcpServerEntry() no longer hard-assumes apps/mcp-server/dist/index.js relative to import.meta.url. Packaged builds set MERONQ_MCP_SERVER_ENTRY (Rust host → bundled path); unset keeps the monorepo fallback for pnpm dev.
  • Pure JS graph@meronq/memory uses node:sqlite (Node ≥22.5), a builtin, not an npm native binding. The whole @meronq/* graph is pure JS and can bundle into a single file. Decision for A2: pin bundled Node ≥22.5.

Small change, but it is the seam that lets the rest of packaging happen.


Why this matters

In development the sidecar is spawned with monorepo-relative paths and node --import tsx. A distributable Tauri app has neither. A1 removes those assumptions so A2–A4 can ship a pinned Node runtime, launch the sidecar from Rust, and supervise it.

pnpm dev (monorepo)
  node --import tsx → sidecar
  MCP entry via ../../../.. paths

packaged app (target)
  bundled Node → sidecar + mcp-server bundles
  MERONQ_MCP_SERVER_ENTRY from Rust host

Next in Sprint 10

Task Focus
A2 Bundle a pinned Node runtime as Tauri externalBin
A3 Launch + supervise the sidecar from Rust
A4 Restart-on-hang watchdog (known write/sync wedge)
A5 tauri build verify on Windows and macOS
A6 Docs + optional CI matrix

Full recap when Sprint 10 closes.


Follow along

← Back to blog