Repository navigation
SAM v3.3.2 — The Yard, Actually
Everything in 3.3.0 — pairing, spend consent, the Pocket's new Settings and filterable task list — plus the three further bugs it took to make the yard genuinely work from a packaged app. This is the one to take.
3.3.0 claimed to fix the yard. It did not, and neither did the first attempt at fixing that. Each bug hid the next.
Fixed
yardDir() never detected a packaged app. It asked whether ROOT contained app.asar — and ROOT is join(dirname(module), "..", ".."), where join normalises. For the bundled layouts a packaged app actually runs, the .. segments eat the app.asar component:
| module | ROOT | contains app.asar? |
|---|---|---|
app.asar/server/yard/store.ts |
…/Resources/app.asar |
yes |
app.asar/dist/server.mjs |
…/Resources |
no |
app.asar/dist-electron/x.js |
…/Resources |
no |
Only the unbundled source layout matched — the one layout a packaged app never uses. The question is now asked of the module path, before normalisation.
The yard could not open its database. server/db.ts exists to pass SAM_SQLITE_BINDING (the native binary that lives outside the read-only asar), and server/yard/store.ts called new Database() directly, skipping it. The app died with Cannot find module .../app.asar/build/Release/better_sqlite3.node the moment the yard was switched on.
The packaged app had no worker at all — the yard · no worker entrypoint — staying down. The electron main bundle lives in app.asar/dist-electron and the worker in app.asar/dist; they are siblings, and every candidate path missed by exactly one level. The store opened, the API answered, and no job would ever have run.
The yard worker could never start on Windows. npm writes tsx, tsx.cmd and tsx.ps1 into node_modules/.bin; the supervisor took the first that existed, and Windows cannot execute a POSIX shell script.
Changed
The release smoke test now proves the thing it claims. It used to boot the app with the yard off — never opening a database, which is the one thing that breaks in a packaged build — and with the checkout as its working directory, so the app ran the repo's TypeScript worker instead of the bundled one. It now runs from a clean directory with the yard on, and fails if the boot log carries an uncaughtException, if the yard cannot find its worker, or if no database appears.
A test also forbids opening a database anywhere but openDb(). It was checked against the file that shipped in 3.3.0, and fails on it.
Signed with a Developer ID certificate and notarized by Apple.
🔒 Verify your download (SHA-256)
The one-paste installers verify this automatically. To check by hand, compute the hash and match:
- macOS/Linux:
shasum -a 256 <file> - Windows (PowerShell):
Get-FileHash <file> -Algorithm SHA256
3c4bb98fe38ab973cd781475a7db4302af8464a34faab12f6b45be3033d9472d SAM-3.3.2-arm64.dmg
8fc7eadfe71a598a7beb24a735f442ab498367809cb63d5c2627d9c765901de4 SAM-3.3.2.AppImage
68429c238b5ee4b09634ba82a5562134cbb7b1e5be579d97ec567781d13cfb2b SAM-3.3.2.dmg
544f800e9ba84a8b7147acf3ceb0daca6cdcf0665f352d9b4664468cbfe3f011 SAM-Setup-3.3.2.exe
2bd6f2c7bea425a4b77600d46da23f2faadb7fb0d9c2dd36b9cd3ad507261d26 sam_3.3.2_amd64.deb