# Shared stylix theming helper: detects an active stylix palette on the # host and renders it as a base16 `colors.css` overlay file. `colors.css` # is the entire theme-swap contract for every frontend bundle in this # project (`theme.css` derives every semantic var from these 16 slots — # see docs/web-ui/css-vars.md), so "apply the operator's stylix palette" # always reduces to "write this one file over the prebuilt dist's own # `colors.css`" — no npm/esbuild rebuild needed. # # Two consumers today: `hive-c0re/theme.nix` (dashboard + agent # frontend), `swarm-ui.nix` (the swarm-level UI). Factored out here # rather than duplicated in both — same "one source, not a copy that # agrees by inspection" reasoning `hive-gateway/vhost-lib.nix` gives for # its own split. Both callers `import` this directly (not published via # an option): unlike the gateway's vhost kit, this needs no per-service # knowledge to construct, it's a pure read of the host's own top-level # `config` — an option indirection would add a layer with nothing to # publish through it. # # Guarded access makes `stylixThemeColors` a clean `null` when stylix # isn't imported into the host config at all, so every caller's own # `if stylixThemeColors != null then ... else ` # stays a zero-op when the operator hasn't opted in. { lib, config, pkgs, }: let stylixThemeColors = if (config.stylix.enable or false) && ((config.lib.stylix or { }) ? colors) then config.lib.stylix.colors.withHashtag else null; themedColorsCss = c: pkgs.writeText "hyperhive-colors.css" '' :root { --base00: ${c.base00}; --base01: ${c.base01}; --base02: ${c.base02}; --base03: ${c.base03}; --base04: ${c.base04}; --base05: ${c.base05}; --base06: ${c.base06}; --base07: ${c.base07}; --base08: ${c.base08}; --base09: ${c.base09}; --base0A: ${c.base0A}; --base0B: ${c.base0B}; --base0C: ${c.base0C}; --base0D: ${c.base0D}; --base0E: ${c.base0E}; --base0F: ${c.base0F}; } ''; in { inherit stylixThemeColors themedColorsCss; }