Skip to content

SAM v3.3.2 — The Yard, Actually

Choose a tag to compare

@richhabits richhabits released this 10 Aug 15:30
· 469 commits to main since this release
2705142

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