Getting StartedOwnable model, workflow, and first local install 2
Overview
Quick Start
FormInstallable form components 1
Input
ToolingCLI and registry contracts 2
CLI
Registry
ReleasePublishing and workflow structure for the ownable surface 1
Release Workflow

Ownable

TailNG ownable installs copy registry-backed source into your app so your team can edit, theme, and ship local component implementations without forking the entire library.

Why ownable exists

Some teams want more than package-level composition. They want generated source they can version, refactor, and review in the same codebase as the product using it.

  • Keep primitives and component behavior, but own the generated wrapper source.
  • Adjust markup, styling, defaults, and internal composition without waiting on package releases.
  • Use the CLI and registry as the single supported source for local installs.

What gets generated

Each registry item declares the files written into your app, along with the import symbols and install hints shown by the CLI and docs.

src/app/tailng-ui/button/
  tng-press-primitive.ts
  tng-button.ts
  tng-button.html
  tng-button.css
  index.ts

When to use ownable

Use ownable installs when the generated source is expected to diverge from the stock package surface in a durable way.

  • Product-specific visual systems that need local markup or file ownership.
  • Teams that want direct code review on wrapper changes inside the app repo.
  • Apps that need a controlled bridge between package behavior and local implementation.

Source of truth

TailNG keeps the ownable contract centralized in @tailng-ui/registry. The CLI, docs, generated file lists, and import snippets all read from that same registry metadata so the surface does not drift.