# Registry

Every release publishes `dist/baseui.registry.json`. The registry lists package metadata, CDN paths, build files, themes, and per-component metadata (type, dependencies, `b-*` attributes, events, and — since the Phase 8 pure-Owl rollout — Owl component/template metadata). It only registers components under `src/components/`; example blocks under `examples/blocks/` are not part of the registry.

BaseUI ships as bundled files only — there is no per-component source distribution. Use the registry's `components` entries to look up a component's contract, not to locate individual source files.

## Build files

`buildFiles` lists every top-level `dist/` artifact the release validates and hashes:

- `baseui.min.css` — Bootstrap 5 + BaseUI styles (static and pure Owl APIs share the same stylesheet).
- `baseui.min.js` / `baseui.esm.js` — the one bundle for both APIs: the static `b-ui` runtime (`BaseUI.register(...)`, `BaseUI.mountAll()`), the Owl framework (`Component`, `mount`, `xml`, ...), every pure Owl component class (`Button`, `Card`, `Tabs`, ...), and the theme helper (`createThemeController`, `BaseUITheme`). Bootstrap's JS bundle and Owl's global build are embedded ahead of BaseUI's own code, in that load order — no separate `baseui.owl.*`/`baseui.components.esm.js`/`baseui.theme.esm.js`/`bootstrap.bundle.min.js` script is needed.
- `bootstrap.bundle.min.js` — vendored Bootstrap JS, standalone, unmodified. Ships in case a project wants it on its own; BaseUI's own bundle never needs it loaded separately (it's embedded in `baseui.min.js`/`baseui.esm.js` too).
- `baseui.icons.esm.js` — the 2000+ generated `Icon<Name>` components (`IconEye`, `IconSearch`, ...), split out because they'd blow the main bundle's size budget. The one deliberate exception to "everything is one bundle".
- `baseui.templates.xml` — every pure Owl component's compiled `<templates>` body, concatenated into one file. Load this into the Owl `App`'s `templates` config before mounting; `.xml` files under `src/components/` are authoring sources, not something a consumer app loads directly.
- `icons/lucide.json` — the built-in icon manifest.

## Component export policy

Every component folder under `src/components/<name>/` is one of:

1. **Both APIs** — has `<name>.js` (static `BaseUI.register(...)` adapter) *and* `<name>.component.js` (pure Owl `Component` class(es)). As of the Phase 8 rollout this is **all 65** registry components; there are no static-only exceptions left. A handful of components (`chart`, most notably) have lighter-fidelity pure Owl treatments than their static adapter — see their component doc page for the documented gap — but every registry component has a real Owl export.
2. Static-only components would report `"type": "static"` with no `owlComponents` field, but none currently exist in this registry.

Per-component registry entries now include:

- `owlComponents` — the exact list of exported Owl class names from `<name>.component.js`, e.g. `["Dialog", "DialogTrigger", "DialogContent", ...]` for compound components. Import these from `@thebase/ui`.
- `templateName` — the namespaced template name the component's *root* class renders, e.g. `"baseui.Dialog"`. Every template also registers a short un-namespaced alias (e.g. `Dialog`) via `t-call` for local convenience; `templateName` documents the namespaced form because that's the collision-safe one to rely on across a large template set.

Existing fields (`type`, `dependencies`, `attributes`, `events`) are unchanged and describe the static `b-ui` contract; they apply regardless of whether an Owl export also exists.

## Validation

The build validates every registry path against `dist/` and adds SHA-384 integrity hashes for build files and themes. Example blocks (composed static HTML demos styled by `baseui.min.css`) live under `examples/blocks/` with per-block CSS split from `examples/blocks/shared.css`, but are not registry or JavaScript components.