| Filename | Latest commit message | Latest commit date |
|---|---|---|
e14887164b
Mara on PR#3315: "shouldnt the pattern be that the old dashboard has a dep on preact and has a preact instance running for the jobq view? then we could get rid of a lot of extra plumbing" - right: the plain h() authoring existed only to dodge adding JSX support to the dashboard's esbuild config, and that dodge is exactly the plumbing to remove now that the dashboard already depends on preact. - JobqGraph.js -> JobqGraph.jsx, rewritten in real JSX. - dashboard/build.mjs: added jsx: 'automatic', jsxImportSource: 'preact' to the JS-bundle esbuild call (esbuild already picks the jsx loader for .jsx by extension; this just sets the transform mode, matching swarm-ui's config). No other entry in that bundle uses JSX today. - shared/package.json: export target updated to the .jsx file. The CSS-as-page-level-@import structure is unchanged and stays that way regardless of JSX: dashboard bundles this component transitively through one esbuild call whose .css loader is 'text' (for the shadow-DOM components that need their CSS as a literal string), and esbuild's loader map is global per call, not per-module - importing CSS from this component would silently pick up that loader too. Explained in the file's own top comment. Verified: npm run build (whole workspace) and npm run typecheck (swarm-ui) clean. Re-ran the same headless-chromium screenshot against a mock GET /api/jobq/graph payload as the previous verification - pixel-identical to the h()-based version, confirming this is a pure authoring-style refactor with no behavior change. |
||
| .. | ||
| packages | ||
| .gitignore | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
hyperhive frontend
npm workspaces project for the hyperhive browser-facing assets:
packages/shared/— shared modules used by both surfaces (terminal pane, Catppuccin palette + body typography).packages/dashboard/— the hive-c0re dashboard SPA.packages/agent/— the per-container web UI (default agent page, stats, screen).
Build
npm install # one-off; uses the checked-in package-lock.json
npm run build # builds every workspace into packages/*/dist/
The Rust binaries serve packages/dashboard/dist/ and
packages/agent/dist/ via tower_http::ServeDir at runtime; the
build derivation is wired up in nix/modules/frontend.nix. Per-agent
additions are layered on top of the default agent dist via the
hyperhive.frontend.extraFiles option in agent.nix.
Why npm + esbuild
- Hermetic: dependencies vendored via the checked-in lockfile;
buildNpmPackagein nix uses it as the source-of-truth so the output is reproducible without network access at build time. - esbuild: vanilla-JS bundler, no framework runtime overhead.
Each workspace's
build.mjsis ~30 lines. - Single-PR migration: see issue #273 for the design proposal and the four-commit shape (npm scaffold → nix derivations → container plumbing → Rust cutover).