Registry guide
Reading a Gummy registry item
A field guide to Gummy UI’s public registry payloads, shared style dependencies, editable component files, and current installation verification.
By Gummy UI · Published
The registry is a source delivery format
The local public application generates shadcn-compatible JSON payloads for the /r path. A component payload contains a name, type, title, description, dependency information, and one or more editable files. It is not a minified component package or a screenshot reference. The value of the format is that a consumer can read the TypeScript and CSS that will enter a project before deciding to use it.
The canonical manifest currently describes 57 component entries and four shared material payloads. The generated JSON is derived from that manifest and the public source tree. Catalogue detail pages link to the relevant payload and show an install command, while the registry index explains the shared foundation.
Follow shared dependencies
Material is split into a base theme and focused shared style files so every component does not duplicate the same tokens and responsive rules. Registry dependencies point to public Gummy URLs such as the base theme, form styles, primitive styles, or core component material. Package dependencies are declared separately for components that use Base UI.
This graph matters during review. A component source file may look intentionally small because its states are expressed in a shared stylesheet. Reading only the TSX can miss theme, RTL, touch-target, or reduced-motion behavior; reading only the CSS can miss the native element or primitive that owns interaction. The payload connects those parts without exposing website-only composition styles.
Understand what verification proves
The current registry verifier checks schema identity, duplicate names and targets, required metadata, public registry dependency URLs, and the presence of every catalogue item. It copies the declared files into an isolated temporary directory and type-checks all canonical component sources. It also checks selected shared styles for RTL, reduced-motion, and separation from website selectors.
That evidence proves that the manifest’s files are readable, copyable, and type-safe against the local dependency set. It does not yet prove every package-manager command in a freshly generated Next.js or Vite application. The project documentation keeps that distinction explicit so a temporary fixture is not mistaken for the complete clean-consumer launch gate.
Review before copying
Start at a component detail page, read its semantics and keyboard notes, then open the registry JSON. Check whether the payload adds a package dependency and which shared material files it resolves. After installation, keep the source editable and preserve the underlying behavior when adapting visual tokens or composition.
If a component change affects public props, semantics, shared styles, or dependency relationships, its manifest, generated payload, documentation, tests, and changelog should move together. That keeps the delivery format aligned with the source rather than turning the registry into a stale export.