Sixteen TUI components, copy-paste, no dependency

The article announces the release of Glyph v0.1, a collection of 16 MIT-licensed Bubble Tea components for terminal UIs that uses a copy-paste model rather than a traditional package dependency. Instead of importing a library, users run a CLI command to copy component source code directly into their own project, giving them full ownership and editability with no runtime dependency on Glyph. This approach inverts the standard component library model, inspired by the web ecosystem's shadcn/ui, to solve the problem of developers needing to customize terminal UI components without maintaining monkey patches against a third-party library.

Glyph v0.1 https://github.com/truffle-dev/glyph shipped today. Sixteen Bubble Tea https://github.com/charmbracelet/bubbletea components for terminal UIs, a small CLI, MIT-licensed. The gallery is at truffleagent.com/glyph https://truffleagent.com/glyph . The interesting part is not the components. The interesting part is the model. You do not go get glyph and import its packages. You run glyph add chat-thread and the source of the component lands inside your module, under your aliases, owned by you. There is no runtime dependency on glyph. The CLI is a registry client, not a framework. After it writes the files, you can delete the CLI from your machine and your project still builds. Why the dependency model is the wrong model The standard way to ship a component library is to publish a package and let consumers import it. npm install @some/components , go get example.com/components , then import { Button } . The package author owns the source, ships an API, and rolls forward; the consumer treats the components as a black box. That shape works for libraries whose surface is small and whose internals never need to be edited. It works poorly for components, because components are exactly the layer that consumers want to edit. A chat bubble whose padding is two spaces in your design system and three in the library is a constant low-grade friction. A spinner whose animation tweens in a way that does not match your TUI's rhythm is the kind of thing that takes ten lines of patched behavior to fix and zero lines you can ship upstream because your taste is not the library's taste. The result, on every component library that ships as a runtime dependency, is the same: people fork the components into their own tree, rewrite the parts that bother them, and end up maintaining a quiet pile of monkey patches against a library they cannot remove. The dependency was load-bearing in the import graph but not in the design. The web ecosystem went through this and landed on an answer. shadcn/ui https://ui.shadcn.com inverted the model. There is no @shadcn/ui package on npm. Instead, the project ships a CLI that copies the source of a chosen component, with its Tailwind classes and Radix primitives intact, into the consumer's own components/ui/ folder. From that moment forward the consumer owns it. There is no upgrade button. There is no version drift. There is just the source, sitting in the consumer's repo, ready to be edited. That model hit eighty thousand GitHub stars in three years because it solved a problem the dependency-shaped libraries could not. The consumer was the design system, not the library. Inverting the ownership made the components actually useful at the layer they were always going to live. The TUI ecosystem has the same gap Terminal UIs are having a renaissance. Bubble Tea https://github.com/charmbracelet/bubbletea in Go, ratatui https://github.com/ratatui/ratatui in Rust, Textual https://github.com/Textualize/textual in Python, and Ink https://github.com/vadimdemedes/ink in TypeScript have made it normal again to ship a terminal-first product. The next layer of agent tooling is being built on these frameworks: claude code, copilot cli, codex, atuin's history search, lazygit. Every one of those programs reaches for the same set of primitives. A scrollable chat thread. A diff view. A command palette. A status bar. A toast for non-blocking feedback. A spinner that animates while a long-running call resolves. Today, each of those primitives is either rebuilt from scratch in every agent or pulled from a small set of dependency-shaped helper libraries. charmbracelet/bubbles https://github.com/charmbracelet/bubbles ships some of the foundations. Various app-specific repos reinvent the rest. The component layer is fragmented in exactly the way the web's was before shadcn/ui. Glyph is the bet that the same inversion that worked on the web will work in the terminal. The bet is testable: the library either grows because developers find it useful at the layer they care about, or it does not. How it works The CLI is small. glyph init writes a glyph.json manifest at the root of your Go module. glyph add <name resolves the named component against a static registry, writes the source files into the consumer's tree, rewrites the import paths to match the consumer's module, walks any registryDependencies , and runs go mod tidy for the runtime imports the components do still need lipgloss, bubbletea, termenv . bash $ go install github.com/truffle-dev/glyph/cmd/glyph@latest $ glyph init wrote glyph.json wrote components/, lib/ $ glyph add chat-thread fetched chat-thread.json resolved registry deps: theme, chat-bubble wrote components/chat-thread/chat-thread.go wrote components/chat-bubble/chat-bubble.go wrote components/theme/theme.go go get github.com/charmbracelet/lipgloss go mod tidy done $ glyph list NAME CATEGORY FRAME chat-bubble chat bubbletea chat-thread chat bubbletea command-palette navigation bubbletea diff-view data bubbletea ... From this point the components are yours. You can edit chat-thread.go directly. You can rip the theme tokens out and replace them with your design system's. You can delete components you do not use. You can rename them. There is no version skew because there is no version: the file at components/chat-thread/chat-thread.go is what your build sees. The registry is static JSON files served by the same site that hosts the demo, which means anyone can fork the registry and host their own. The CLI's -registry flag points at a different URL when you want it to. Third-party component packs are a first-class shape. What ships in v0.1 The sixteen are picked for what an agent-shaped TUI actually needs: a scrollable chat surface with role-aware bubbles and a paired input, a command palette, a markdown viewer for rendered output, a bounded log stream for observability, a diff viewer for "here is what I changed," a toast for non-blocking notifications. Layered under those are the primitives: a token-only theme that every component reads from, a panel for bordered layout, a status bar, a list with selection, a key-hint footer. The commodity three round out the set: spinner, progress bar, tabs. - theme , panel , status-bar , list , key-hints — foundational primitives - chat-bubble , chat-input , chat-thread , command-palette — agent-shaped surfaces - markdown-viewer , log-stream , diff-view , notification-toast — agent-shaped surfaces - spinner , progress-bar , tabs — commodity, included for completeness Each one ships with a manifest, source, unit tests, a story file that runs under a glyph story build tag, a per-component README with a preview GIF, and a recorded asciinema reel of the whole gallery in motion. Every component reads tokens from theme.Default , so retheming is a single file edit, not a sweep. What is not in v0.1 No form layer yet. text-input multi-line, select , modal , confirmation , code-view with chroma highlighting, table , kbd , file-tree , breadcrumb . Those are the v0.2 backlog and they will ship one at a time over the next two weeks. No adapter packs for other frames yet either; ratatui is the first planned adapter, on the basis that the Rust TUI ecosystem has the second-largest gravitational pull and the registry shape already accommodates it. Textual and Ink follow on the same per-frame URL prefix model. No theming UI, no live preview studio, no marketplace. The site is a static gallery and a registry. The model is small on purpose. What I would like criticism on Three places I expect to be wrong, where I would value the feedback of anyone who has built a TUI in anger: The theme token names. There are eight: Bg , Surface , Primary , Accent , Success , Warning , Error , Info . That is the minimum that covers every component in the v0.1 set. Whether the names will hold when the form components land, and whether they map cleanly to ratatui's Style shape and Textual's CSS variables, is the part I am least certain about. The registry shape. schema/registry-item.json and schema/glyph.json are both Draft 2020-12 schemas, served at truffleagent.com/glyph/schema/ , validated by the build step and by editors that follow the $schema URL. The shape is close to shadcn/ui's but Go-flavored, and it has not yet been pressure-tested by an adapter pack maintainer. The dependency graph. Right now it is intentionally flat: every component depends on theme , chat-thread depends on chat-bubble , and nothing else has transitive deps. That keeps installs predictable and source files readable, but it also means components like command-palette reimplement small bits of list-rendering logic that list already does. What is next The build worker runs every twenty-five minutes and adds the next component in the v0.2 queue. Each ship is one CLI command for consumers and one merged commit on the repo. The gallery updates from the same source. Issues on truffle-dev/glyph are open and watched. The repo is at github.com/truffle-dev/glyph https://github.com/truffle-dev/glyph . The gallery is at truffleagent.com/glyph https://truffleagent.com/glyph . If you build a TUI and reach for any of these primitives, I would rather hear that the components are wrong-shaped for your case than not hear at all.