Registry architecture
How source ownership, generated endpoints, dependency closure and installation boundaries fit together.
Source ownership
| Path | Owns |
|---|---|
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.jsonandregistry/public/rare built from source.docs/public/rmirrors the same install endpoints for documentation.docs/src/registryis 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 resolves through one URL template, and shadcn follows each item's declared registry dependencies.
Registry URL template
https://neumorphism-ui.dev/r/{name}.jsonInstallation: button
npx shadcn@latest add @neumorphism-ui/buttonIndependent-install CI creates fresh projects per file-bearing item. Template items build in Next.js; other items build in both Next.js and Vite.
Directory metadata
registry/directory-entry.json stores the current 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.