fix(desktop): verify better-sqlite3's shipped prebuild

[lucas77778]

The v0.27.0 release build failed on all three platforms with:

✗ mac/LinkCode.app/Contents/Resources: missing native binding node_modules/better-sqlite3/build/Release/better_sqlite3.node (better-sqlite3)

better-sqlite3 13 (#443) changed how the binding is distributed. v12 downloaded a per-Node-ABI
build into build/Release/better_sqlite3.node via prebuild-install; v13 ships eight N-API
(NAPI_VERSION=10) prebuilds in the tarball as prebuilds/<platform>-<arch>.node, and its
binding.gyp turns both targets into type: none whenever a prebuild exists. node-gyp therefore
only touches its stamps, @electron/rebuild is a no-op, and nothing is ever written to
build/Release — the packaged app is fine, verify-artifacts.mts was just looking in the old
place. Every other check in that run passed.

verify-artifacts.mts now asserts the target's prebuild instead, keeping the Mach-O/PE/ELF arch
check. Three stale comments about prebuild-install / build/Release are corrected with it.

Verification

• The prebuild loads under Electron 43 (Node 24.18.0, N-API 10) and runs SQL — no rebuild needed.
• Packed an arm64 dev shell: @electron/rebuild stays a no-op and
  app.asar.unpacked/node_modules/better-sqlite3/prebuilds/darwin-arm64.node is in place.
• The updated check reports no problems for that app, and correctly reports the missing
  darwin-x64.node when pointed at an arm64 app as if it were the x64 one.
• Launched the packaged app: the daemon boots and migrates daemon.db, so the shipped prebuild is
  what it loads.
• pnpm check:ci passes.

Follow-up (not in this PR)

v13's tarball carries all eight prebuilds and electron-builder smart-unpacks the whole module, so
every artifact now ships ~15 MB of foreign-platform .node files. Pruning the staging dir down to
the target (plus the host's, which is what keeps binding.gyp from compiling from source) removes
that; left out here to keep the release unblocking minimal.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[greptile-apps]

Greptile Summary

The PR updates desktop artifact verification for better-sqlite3 v13’s shipped N-API prebuild layout instead of expecting the legacy rebuilt binding.

• Maps electron-builder platform names to Node platform tokens and verifies the target architecture’s prebuild.
• Retains native binary architecture validation for macOS, Windows, and Linux artifacts.
• Corrects packaging documentation and comments describing native dependency handling.

Confidence Score: 5/5

The PR appears safe to merge, with the verifier aligned to the shipped better-sqlite3 v13 prebuilds on every supported desktop target.

The supported platform and architecture mappings resolve to the documented v13 prebuild filenames, unsupported platforms are rejected before verification, and the retained native-header checks continue to detect architecture mismatches.

Important Files Changed

Filename	Overview
apps/desktop/scripts/verify-artifacts.mts	Updates better-sqlite3 verification to inspect the target-specific v13 N-API prebuild while preserving binary architecture checks.
apps/desktop/electron-builder.yml	Corrects comments to reflect that packaged applications load better-sqlite3’s shipped prebuild rather than a rebuilt Release binding.
apps/daemon/scripts/package-daemon.mts	Updates packaging documentation to distinguish better-sqlite3’s target prebuilds from host-specific native dependencies.
apps/daemon/AGENTS.md	Aligns daemon packaging guidance with the current native dependency distribution model.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    A[Target platform and architecture] --> B[Map builder platform to Node platform]
    B --> C[Resolve better-sqlite3 prebuild path]
    C --> D[Check app.asar.unpacked]
    D --> E[Validate Mach-O, PE, or ELF architecture]
    E --> F[Accept or reject artifact]

Loading

_{Reviews (1): Last reviewed commit: "fix(desktop): verify better-sqlite3's sh..." | Re-trigger Greptile}

[pullfrog]

ℹ️ The fix itself is correct and I could not find a way for it to fail. Two comment-accuracy points inline, plus two more stale sites the sweep missed.

Reviewed changes — the whole 1-commit diff (4 files), plus independent verification of the better-sqlite3 v13 layout, its binding-resolution order, and electron-builder's smart-unpack behavior against the installed packages.

• verify-artifacts.mts asserts the shipped prebuild — NATIVE_BINDING is replaced by sqliteBinding(platform, arch) over a new NODE_PLATFORM map, targeting node_modules/better-sqlite3/prebuilds/<nodePlatform>-<arch>.node; the Mach-O/PE/ELF arch check is retained and the entry becomes conditional, mirroring keyringBinding.
• Three comment corrections — electron-builder.yml, apps/daemon/scripts/package-daemon.mts, and apps/daemon/AGENTS.md drop their prebuild-install / build/Release claims.

What I verified independently, since the whole PR rests on it:

• better-sqlite3@13.0.2 ships eight flat prebuilds/<platform>-<arch>.node files, gypfile: false, no install script, and binding.gyp sets both targets to type: none when a prebuild exists — so @electron/rebuild really is a no-op and build/ holds only node-gyp stamps.
• lib/binding.js's getPrebuildPath() is tried before build/Release, so the asserted file is genuinely the one the daemon loads.
• app-builder-lib/out/asar/unpackDetector.js adds stat.moduleRootPath to autoUnpackDirs on any .node hit, so the whole better-sqlite3 directory is smart-unpacked — the asserted path is correct for all six mac/win/linux × x64/arm64 targets, not just the arm64 mac the description covers.
• Nothing in .github/workflows/, the packaging scripts, or the E2E suite still references build/Release/better_sqlite3.node.

ℹ️ The stale-comment sweep stops two sites short

The PR corrects three comments but leaves two more carrying the same pre-v13 premise, one of which now directly contradicts an edit in this diff.

Technical details

# Two more `@electron/rebuild` / `build/Release` claims left stale

## Affected sites
- `docs/RELEASE.md:257` — describes this exact gate as "the smartUnpacked `better-sqlite3` binding is
  present and its Mach-O/PE/ELF header targets the app's arch (**the tripwire for the CODE-107
  Windows rebuild miss** …)". There is no rebuild left to miss: `binding.gyp` short-circuits to
  `type: none` and the prebuild is named by arch, so the header check can no longer fail for that
  reason. The sentence should describe what the gate now covers (the prebuild for the target is
  present and smart-unpacked) rather than a tripwire that no longer exists.
- `apps/desktop/scripts/package-app.mts:116` — `pruneStaging`'s doc says "notably
  better-sqlite3/deps must stay HERE in staging because `@electron/rebuild` compiles from it before
  collection", presenting the from-source compile as the routine path. The `electron-builder.yml`
  edit in this diff (new lines 61-63) now says `deps` is "only ever compiled if a from-source
  `@electron/rebuild` happens". The two now disagree about the same fact.

## Required outcome
- Both sites state the post-v13 reality, and `electron-builder.yml` and `package-app.mts` agree on
  whether the `better-sqlite3/deps` compile is routine or conditional.

## Open questions for the human
- Given the compile is now unreachable in practice, is keeping `better-sqlite3/deps` in staging
  still worth stating as a constraint, or has it become a plain "harmless, excluded from the asar
  anyway"? That answer decides how both comments should read.

ℹ️ Nitpicks

• NODE_PLATFORM (verify-artifacts.mts:79-83) has to stay key-for-key with EXPECTED; a fourth platform added to EXPECTED without a matching entry makes sqliteBinding return null and the better-sqlite3 gate disappear silently instead of failing. Partial<Record<string, string>> gives no help here. Not worth a runtime guard — but the two maps being coupled is invisible from either one.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[PeronGH]

Approving — this is necessary, not cosmetic. Without it the next tagged release fails at verify-artifacts.

Verified against a fresh clone of this branch with a real staging closure (pnpm --filter @linkcode/desktop --prod deploy --legacy --cpu=x64, pnpm 11.10.0):

• The closure has exactly one better-sqlite3, and prebuilds/ holds all eight flat files — darwin-arm64.node, win32-x64.node, … The prebuilds/${nodePlatform}-${arch}.node template matches exactly (note it is not the prebuildify directory convention).
• There is no build/ directory at all, so the old build/Release/better_sqlite3.node assertion would fail on every artifact.
• It won't come back via @electron/rebuild: v13's binding.gyp gates both targets on force_build==1 or prebuild_exists==0, where prebuild_exists shells out to node lib/binding.js. In the staged package that prints 1, so both targets collapse to type: none and a plain node-gyp rebuild produces nothing.
• The prebuild loads with no build step — getPrebuildPath() → prebuilds/linux-x64.node, and new Database(':memory:') + pragma('journal_mode = WAL') returns SQLite 3.53.4.

The revised deps/** rationale in electron-builder.yml also checks out: binding.gyp includes: ['deps/common.gypi'] unconditionally, so gyp needs deps/ to parse even in the no-op case.

Two non-blocking points.

1. The check is now close to tautological

Nothing prunes non-target prebuilds. pruneStaging (package-app.mts:118) only drops .map/.ts/.md, and the only better-sqlite3 exclusion in electron-builder.yml is deps/**. So all eight prebuilds ship in every artifact and all eight smart-unpack.

That means prebuilds/darwin-arm64.node is present in the Windows build too, and its header is arm64 by construction — readBinaryArch can never disagree with expectedArch. Under v12 the check was genuinely target-sensitive; it now only proves the tarball wasn't mangled.

Fix that restores it and saves space: prune the seven non-target prebuilds in pruneStaging. That's ~14.3 MB of dead weight per artifact (16.5 MB shipped, 2.2 MB used), and once only the target prebuild survives, the existence + arch assertion means something again.

2. Comment describes a failure mode that doesn't exist yet

verify-artifacts.mts:87 — "what breaks is the staging prune keeping the wrong target" — nothing currently prunes prebuilds per target. Accurate only after the change above.