---
status: accepted
---

# Published preset registers the complete component set

The published `@brightspot/ui` preset (`src/tailwind.config.ts`) registers the **full** component-plugin set plus an explicit `safelist` for runtime-written classes (tooltip/popover position/offset/no-arrow), rather than the minimal `pagination` + `empty-state` list it carried historically. Consumers — including the host CMS — extend the preset and get every component's CSS without maintaining their own per-plugin registration.

### Cost (measured)

**Host impact (the only number that matters for production):** switching the host CMS from its current 10-plugin list to the complete preset adds **≈ +16.9 KB** to the v5.css component layer (≈ +25–34 KB after postcss-rtl). tooltip+popover specifically account for **≈ +7.9 KB** of that, closing the headline tooltip-missing defect. The host's v5.css already ships the heaviest plugins (`button`, `badge`, `icon`, `heading`, `loader`, `scroll-shadow`, `contrast`, `ring-contrast`, `theme`, `container-queries`) — Phase 3 only newly adds the lighter components (action-bar, avatar, button-group, checkbox, dropdown, popover, switch, tabs, tooltip, upload).

---

*Footnote — preset-intrinsic cost:* the standalone preset's component layer grows from ~2.7 KB (bare 2-plugin) to ~1.36 MB (complete). This is **not** the host impact (no production consumer compiles the bare preset — in-CMS consumers rely on the host Monolith per [ADR 0001](./0001-monolith-css-delivery.md)); it's an intrinsic-cost figure. The preset's broad color/size `safelist` patterns force-emit every *registered* component's runtime-applied variants (e.g. `btu-button-primary`, `btu-badge-lg`), so unused components do **not** purge to zero. The original rationale on this page claimed "addComponents is content-purged, so a complete preset costs ~0 for unused components" — that is incorrect when safelist patterns match the component's variants (which they do for most components). The reason completion is cheap *for the host* is that the host already registers the heavy plugins, not purging.

## Why

- Consumers previously hand-maintained their own `plugins[]` list (the host registered ~10 itself), which drifted out of sync. The omission of `tooltip`/`popover` there is exactly why those classes were missing from the Monolith — the tooltip-styles-missing defect. A complete preset removes the per-consumer registration step and the whole class of "forgot to register X" bugs.
- Runtime-written classes (e.g. `TooltipMixin`'s POSITION_CLASSES/OFFSET_CLASSES) are invisible to content scanning, so they must be safelisted in the preset itself — consumers can't be expected to rediscover them.

## Consequences

- The host `cms/tool-ui` config can drop its manual `plugins[]` list and rely on `presets: [require('@brightspot/ui')]`. Before removing it, preset parity must cover everything the host registered (`theme`, `contrast`, `ring-contrast`, `@tailwindcss/container-queries`).
- **Gated on [ADR 0003](./0003-plugin-selector-isolation.md).** Registering cross-referencing plugins (button-group, pagination, dropdown, upload) into the shipped preset is only safe once their foreign `.btu-*` selectors are decoupled — otherwise the `@apply` cross-multiplication detonates (≈ +2.75 MB for button-group alone). Sequence: **isolate first, then complete the preset.**
- See [ADR 0001](./0001-monolith-css-delivery.md): the preset feeds the host-built Monolith, which is the single CSS delivery vehicle for all (in-CMS) consumers.
