Repository navigation
design version surfacing
sinrimin edited this page Sep 30, 2026
·
1 revision
Issue: #37. Before: the daemon reported a hand-invented
DAEMON_VERSION = '0.25.0-i6', the server exposed no version anywhere, hnx
had no --version, and the UI showed none.
- The five publishable packages version in lockstep;
packages/serveris not one of them (its manifest stays0.0.0), so the SERVER's build version is read from@harness-nexus/shared's manifest (itspackage.jsonis exported explicitly for this). The daemon reports its CLI package version. Comparing the two is therefore meaningful. -
Mismatch warns, never blocks. The
machine:helloproto number stays the compatibility gate; pre-1.0 alphas must keep connecting across a skew.
- shared:
compareVersions()(semver-shaped, zero deps, tolerant of0.1.0-alpha.7/0.1/ junk) + unit tests. - server:
GET /api/system/info(auth) →{ version }; themachine:helloack now carriesserverVersion. - cli:
hnx --version; the daemon's online line includes the version (hnx daemon: online (cli 0.1.0-alpha.7, proto 1, machine …)) and prints a one-line upgrade hint per connect when older than the server. - sdk:
getSystemInfo()+compareVersionsre-export (web depends on sdk only). - web:
<VersionLine>— one muted mono line above the account block in the plate foot and the mobile drawer foot (no persistent phone chrome cost); unknown version renders nothing. The Machines page daemon chip turns warn-ink with an upgrade tooltip whendaemonVersion < serverVersion(fetched once per session, module-cached inapps/web/src/version.ts).
Dev QoL riding along: VITE_API_TARGET overrides the vite dev proxy target,
so a second stack can run beside the default :8080.
"Above the user card in the menu" was the user's suggestion with a worry about phone crowding. Resolved as: the line lives INSIDE the two collapsible surfaces (plate foot / drawer foot), costing one line only where the account block already is — the phone's persistent chrome is untouched, and the version is still one tap away.