| Filename | Latest commit message | Latest commit date |
|---|---|---|
a588ed42ce
mara: 'wait the common styles is literally just the button stuff? pls make a button component now as part of this pr and replace the usage in the modal. replacing all usages and finally removing the btn styles from common css is a follow up then.' <hive-btn> (hive-btn.js) is a customized built-in <button is="hive-btn"> with its own shadow root -- extending HTMLButtonElement keeps every native button behaviour (click/keyboard activation, :disabled, form participation) instead of re-implementing it on a generic wrapper. Shadow root holds only an adopted stylesheet + a <slot>, so the button's light-DOM content (label, or asyncBtn's swapped-in spinner span) renders through unchanged -- slotted content stays styled by the light-DOM cascade, so the global .spinner class still applies. Variants (cancel/confirm/danger) are a 'variant' attribute, not a CSS class, since they're a semantic prop of the component. Customized built-ins aren't supported in Safari/WebKit -- fine here, the project targets recent Firefox only (same reasoning as the original custom-elements pilot). Wired into modal.js: HiveDialog's buttons now render as <button is="hive-btn" variant="...">, replacing the old component-common.css .btn copy -- deleted that file + component- styles.js entirely (their sole purpose was giving dialog buttons a .btn look, which hive-btn now owns properly). dom.js's el() gained support so it can create customized built-ins the same way it creates everything else. hive-dialog.css dropped the now-dead .cancel/.confirm/.confirm.danger rules. Per mara's scoping: NOT touching the other .btn consumers across the app (dashboard/agent submit buttons, form() helper, etc.) or removing .btn from dashboard/common.css / agent/agent.css in this PR -- that migration + cleanup is an explicit follow-up. Verified with a full frontend build (grepped bundled JS for hive-btn/ variant to confirm it inlines); nix fmt clean. |
||
| .. | ||
| 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).