Four design systems, one repo.
Mono-Happnest ships four front-end packages that each present a different face to a different audience. This guide explains how the design tokens, fonts, and component recipes flow between them — and what's still left to refactor.
At a glance
Click into any package to see its tokens, typography, code, and plan walkthrough.
@happnest/core
Planned
Shared component library — Button, Card, Modal, Input… Used by every consumer. Being refactored to read tokens from a public CSS-variable contract.
@happnest/client
Shipped
Guest-facing booking app. Off-white background, deep teal accent, Fraunces + Manrope. Hotel themes via [data-theme].
@happnest/webcheckin
Shipped
Mobile-first guest check-in. Calmer neutral default + runtime hotel branding via --hotel-*. iOS-safe (16 px inputs, 44 px touch). All 10 steps done · 19 suites / 177 tests passing.
@happnest/enterprise
Shipped
Admin/back-office. Per-client branding injected at runtime. Fully decoupled from @pamaconu/core — 12 local primitives, all 168 TSX files swept, 0 hardcoded literals remaining.
The token flow
The big idea of the in-flight refactor: core stops baking colors in, and instead reads from a small public contract of CSS variables.
Each consumer owns its own tokens.css and imports core's recipes.
Admin & enterprise keep working because legacy variables stay in place.
--font-body: Manrope
(+ --hotel-* runtime)
(+ admin legacy vars)
.core-btn, .core-card, .core-modal …
Reads
hsl(var(--accent)), var(--radius-md), …Why now?
The problem
Until recently every consumer pulled core's globals.css, which baked the admin/enterprise monochrome palette.
When client wanted a teal accent for the guest booking flow, the only options were per-package if-statements or forking core components.
Webchecking faced the same wall with multi-tenant hotel branding.
The fix
A small public contract of CSS variables (--accent, --bg, --ink, --radius-md, --font-body, …)
owned by each consumer. Core ships a hand-authored components.css that uses only those variables.
Consumers swap the values; core never has to change.
Suggested reading order
- Client — finished example. Shows what the end state looks like for a consumer.
- Webcheckin — same shape as client, plus a runtime-branding twist.
- Core — the big in-flight refactor that ties it all together.
- Enterprise — already shipped, lives in parallel; useful for contrast.