Skip to main content

Component Registry

Relevant source files

Purpose and Scope

The Component Registry is a centralized metadata system that catalogs all components in @ui8kit/core and enables multiple installation and consumption patterns. The registry is defined in src/registry.json1-281 and provides structured metadata including component names, types, dependencies, file paths, and target directories. This page documents the registry format, component metadata schema, registration process, and how the registry powers different installation methods. For information about the build pipeline that generates registry artifacts, see Build System. For details on package distribution, see Package Structure. Sources: src/registry.json1-281 README.md251-276

Registry File Structure

The registry is a JSON file conforming to the buildy-ui schema. It contains three top-level properties: Sources: src/registry.json2-281

Registry Schema Diagram

Sources: src/registry.json2-10 src/registry.json278-281

Component Metadata Schema

Each component entry in the items array contains the following fields: Sources: src/registry.json4-17

Component Types Distribution

The registry contains 18 components across two types: Sources: src/registry.json2-276

Example Component Entry

The Button component demonstrates a minimal registry entry:
Sources: src/registry.json156-169

Dependency Classification

The registry tracks two categories of dependencies for each component:

Runtime Dependencies

Components declare runtime dependencies that must be installed in the consumer application: Note: class-variance-authority, clsx, and tailwind-merge are package-level dependencies defined in package.json48-53 and not tracked per-component.

Development Dependencies

The devDependencies array is present in all entries but typically empty, as development dependencies are managed at the package level in package.json59-66 Sources: src/registry.json8-10 src/registry.json54-56 src/registry.json266-268 package.json48-53

File Path Mapping

Each component entry maps source files to target directories in the consumer project:

Target Directory Structure

File Mapping Diagram

Sources: src/registry.json14-16 src/registry.json240-243 src/registry.json272-274

Registry Generation

The registry is generated and maintained through the buildy-ui CLI tool:

Scan Command

The scan script in package.json26 executes the buildy-ui scanner:
This command:
  1. Scans component directories (src/components/ui/, src/layouts/)
  2. Extracts component metadata from source files
  3. Determines dependencies by analyzing imports
  4. Updates src/registry.json1-281 with current metadata
  5. Sets lastUpdated timestamp to current ISO 8601 time
Sources: package.json26 src/registry.json279

Build Registry Command

The build:r script in package.json27 generates distribution artifacts:
This creates the published registry package at packages/registry/ for programmatic access. Sources: package.json27-28

Integration with Installation Methods

The registry powers four distinct installation patterns:

Installation Methods Comparison

Sources: README.md255-276

Per-Component Installation Flow

Sources: README.md261-265 src/registry.json156-169

Programmatic Registry Access

Applications can import the registry JSON for automation and tooling:

Registry Data Structure

Example Usage

Sources: README.md268-276 src/registry.json1-281

Component Coverage

The registry provides complete coverage of the library’s component hierarchy:

Component Inventory by Layer

Sources: src/registry.json1-276

Registry Maintenance

Version Management

The registry uses semantic versioning independently from the package version: The registry version changes when the metadata schema changes, not when components are added or modified.

Last Updated Timestamp

The lastUpdated field in src/registry.json279 records the last modification time as an ISO 8601 string:
This timestamp updates automatically when running npm run scan. Sources: src/registry.json278-281 package.json3 package.json26

Registry Distribution

The registry is distributed through two channels:

NPM Package Distribution

The registry JSON is included in the NPM package through the files field in package.json39-42:
Note: The registry.json is not explicitly listed here but is included in the NPM tarball for programmatic access.

Standalone Registry Package

The publish script in package.json28 publishes a standalone registry package:
This creates a dedicated NPM package containing only the registry metadata for lightweight access by CLI tools. Sources: package.json28 package.json39-42

Integration with Build Pipeline

The registry interacts with other build-time systems:
Sources: package.json22-28 src/registry.json1-281

Summary

The Component Registry serves as the single source of truth for component metadata in @ui8kit/core. It enables:
  1. Per-component installation via npx buildy-ui add [component]
  2. Programmatic access for tooling and automation
  3. Dependency tracking for selective installations
  4. File path mapping from source to target directories
  5. Component classification by type (UI vs Layout)
The registry is automatically maintained through the buildy-ui scan command and distributed via NPM alongside the compiled package. Sources: src/registry.json1-281 README.md251-276 package.json26-28