Registry architecture
How source ownership, generated endpoints, dependencies and installation boundaries fit together.
Source ownership
| Path | Responsibility |
|---|---|
registry/src/components/ui | Installable UI primitives |
registry/src/components/blocks | Templates, workspaces and chart recipes |
registry/src/lib | Shared utilities and analytics model |
registry/src/theme.ts | Preset data and token calculation |
registry/catalog.json | Item metadata and dependency declarations |
Generated output
registry/registry.json · registry/public/r— Built from registry source.docs/public/r— Mirrors the same install endpoints for documentation.docs/src/registry— A synchronized, ignored build input, not a second source of truth.- Generated CSS and theme bootstrap come from the same theme engine.
Installation flow
@neumorphism-ui — The namespace resolves through one URL template. shadcn follows each item's declared registry dependencies. Install the shared base once before adding components.
https://neumorphism-ui.andongmin.com/r/{name}.jsonnpx shadcn@latest add @neumorphism-ui/buttonFull independent installation checks run locally or through the manual comprehensive workflow. Template items build in fresh Next.js projects; other file-bearing items build in both Next.js and Vite. Default CI checks representative consumers.
Directory metadata
registry/directory-entry.json — Stores the namespace, homepage, endpoint template, description and inline logo. Its presence does not imply directory submission or approval.
Boundaries
- The registry does not own application authentication, authorization, persistence, routing or business data.
- Component installation must not overwrite application-owned CSS, customized source, aliases or routes.
- Obsolete paths are removed instead of kept behind compatibility aliases.