Skip to content

feat(updates): in-app pill announces newer npm-published versions - #10

Merged
bjb2 merged 1 commit into
mainfrom
feat/update-check
May 29, 2026
Merged

bjb2 merged 1 commit into
mainfrom
feat/update-check

Conversation

@bjb2

@bjb2 bjb2 commented May 29, 2026

Copy link
Copy Markdown
Owner

What it does

A small ↑ 0.7.0 available pill appears in the StatusBar (bottom of the deck) when a newer version of omp-deck has been published to npm. Click it → opens GitHub releases in a new tab → user reads what changed → user updates manually with npm install -g omp-deck@latest.

That's the entire feature. No auto-update, no nag dialog, no telemetry.

Design constraints

Never auto-updates We inform; the user runs the install. Auto-replacing a running install is out of scope.
Never blocks the app Boot fires fire-and-forget cache prime. /api/version returns the cached value immediately and triggers a background refresh if stale.
Never leaks telemetry Fetches https://registry.npmjs.org/omp-deck with the abbreviated metadata Accept header. Same destination as npm install itself. No version-as-fingerprint, no analytics.
Always graceful on failure Registry down, corrupt cache, unparseable response, env-disabled → all paths return updateAvailable: false and the pill stays hidden.
Disable knob OMP_DECK_DISABLE_UPDATE_CHECK=1 short-circuits everything (no cache read, no network). Documented in CHANGELOG when shipped.

Cache layout

<dataDir>/update-check.json:

{ "checkedAt": "ISO-timestamp", "latest": "0.7.0", "registryUrl": "..." }

24-hour refresh interval. latest: null distinguishes "tried and errored" from "never fetched" — neither shows a pill.

Semver-awareness

Uses Bun.semver.order for comparison so:

  • 0.10.0 > 0.9.0 (not lexicographic)
  • 1.0.0-beta < 1.0.0 (prerelease handling)
  • malformed input returns 0 (treat as no update — safer than guessing)

Files

apps/server/src/update-check.ts             (new, ~250 LOC — fetch, cache, compare)
apps/server/src/update-check.test.ts        (new, 10 tests, 33 assertions)
apps/server/src/routes.ts                   GET /api/version wiring
apps/server/src/index.ts                    primeUpdateCheckOnBoot() in main()
apps/web/src/components/chrome/UpdatePill.tsx  (new — fetch on mount, render only if updateAvailable)
apps/web/src/components/chrome/StatusBar.tsx   <UpdatePill /> placement
packages/protocol/src/index.ts              VersionInfo type

Verification

  • 10 new unit tests cover: disabled env var (truthy/falsy variants), cache hit with newer/same/older versions, semver-aware comparison, prerelease handling, registry-error state, first-call empty state + background refresh, response shape (releaseUrl + packageUrl present)
  • Stubbed globalThis.fetch for network paths; seedCache writes the cache directly for cache-read paths — no test depends on registry reachability or background-refresh timing
  • Full server suite: 191/191 pass (was 181)
  • Typecheck across all 4 packages: clean

Out of scope (possible follow-ups)

  • Settings panel to toggle the kill switch from the UI (env var is the only way today)
  • Release-notes excerpt in a hover tooltip
  • Notification toast on first detection (currently pill-only; intentional restraint — toast could feel spammy)

When a newer version is published to npm, the StatusBar at the bottom
of the deck surfaces a small `\u2191 X.Y.Z available` pill linking to the
GitHub releases page. Click \u2192 read what's new \u2192 update with
`npm install -g omp-deck@latest` in your terminal.

Constraints respected:
- **Never auto-updates.** Only informs; the user runs npm install
  themselves. Auto-replacing a running install is out of scope.
- **Never blocks the app.** Boot fires a fire-and-forget cache prime
  via setTimeout. The /api/version route returns the cached value
  immediately and triggers a background refresh if stale.
- **Never leaks telemetry.** Fetches https://registry.npmjs.org/omp-deck
  with the abbreviated metadata Accept header. Same destination as
  the install itself; no version-string-as-fingerprint, no analytics.
- **Always graceful on failure.** Registry down, corrupt cache,
  unparseable response, env-disabled \u2192 all paths return
  `updateAvailable: false` and the pill stays hidden.
- **Disable knob:** `OMP_DECK_DISABLE_UPDATE_CHECK=1` short-circuits
  everything (no cache read, no network).

Cache layout (`<dataDir>/update-check.json`):
  { checkedAt: ISO, latest: 'X.Y.Z' | null, registryUrl: '...' }
24-hour refresh interval. `latest: null` distinguishes 'tried and
errored' from 'never fetched'.

Semver-aware comparison via `Bun.semver.order` so 0.10.0 > 0.9.0
correctly, and prereleases (1.0.0-beta < 1.0.0) are handled.

Server surface:
- apps/server/src/update-check.ts            (new, ~250 LOC)
- apps/server/src/update-check.test.ts       (new, 10 tests, 33 assertions)
- apps/server/src/routes.ts                  GET /api/version
- apps/server/src/index.ts                   primeUpdateCheckOnBoot()

Web surface:
- apps/web/src/components/chrome/UpdatePill.tsx (new, fetch-on-mount)
- apps/web/src/components/chrome/StatusBar.tsx  <UpdatePill /> placement

Protocol:
- VersionInfo type with the disabled/latest/updateAvailable triad

Tests: 191/191 pass (was 181); typecheck clean across 4 packages.

Out of scope (possible follow-ups):
- Settings panel to toggle the kill switch from the UI
- Show release-notes excerpt in a hover tooltip
- Notification toast on first detection of a new version (currently
  pill-only; intentional restraint)
@bjb2
bjb2 merged commit 1244029 into main May 29, 2026
4 checks passed
bjb2 added a commit that referenced this pull request May 29, 2026
Tiny follow-up to v0.6.0. Bumps all 4 package.json versions to 0.6.1
in lockstep and documents the update-check pill (#10) in the
changelog.

The whole point of this release is to get the update-check pill into
users' hands so future releases (v0.6.2+) become discoverable from
inside the deck. v0.6.0 users will see the pill announcing 0.6.1 as
soon as they upgrade, since the pill hits npmjs.com on a 24h cycle.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant