vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
hyperhive/frontend
History
Repository files (latest commit first)
Filename Latest commit message Latest commit date
iris 38aa5f77f4 frontend: guard hive-menu/hive-agent-menu connectedCallback against reconnect 
Fixes hyperhive#2893: 'Element.attachShadow: Unable to re-attach to
existing ShadowDOM', crashing swarm.js's live-update render path.

A custom element's connectedCallback fires again on a same-document
*move* (insertBefore/append repositioning an already-connected node
runs the removal + insertion steps for its whole subtree), not just
on a fresh mount. swarm.js's row-fingerprint cache reuses + reorders
existing <li> subtrees on live updates -- reordering an unchanged,
cached row moves its already-initialised <hive-agent-menu>/<hive-menu>
without ever really detaching it from the document, so connectedCallback
re-runs full setup on an instance that's already set up. attachShadow()
throws unconditionally if the host already has a shadow root, and
HiveAgentMenu's unconditional child-menu creation would have appended a
second <hive-menu> on top of the first, doubling the dropdown, once the
shadow-attach crash itself was out of the way.

Both connectedCallbacks now bail early if already initialised
(shadowRoot present / _menu already built). Reproduced the crash and
duplicate-menu bug with an unguarded control copy of both files driven
via headless Chromium (simulating the exact row-reorder move), then
confirmed the guarded version throws nothing, keeps the same shadowRoot
object identity across the move, and doesn't duplicate the dropdown.
2026-08-01 01:57:06 +02:00
..
packages frontend: guard hive-menu/hive-agent-menu connectedCallback against reconnect 2026-08-01 01:57:06 +02:00
.gitignore frontend: add npm workspace scaffold under frontend/ 2026-05-23 14:51:01 +02:00
package-lock.json chore(frontend): update npm dependencies 2026-07-15 23:30:25 +02:00
package.json chore(frontend): update npm dependencies 2026-07-15 23:30:25 +02:00
README.md frontend: add npm workspace scaffold under frontend/ 2026-05-23 14:51:01 +02:00

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; buildNpmPackage in 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.mjs is ~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).