Col

Sol could not do it himself, so we made Col.

A community-maintained directory for finding the right UI library without losing an afternoon to open tabs.

Request a library · Request a feature · Report a bug · Contribute

What Col does

Col organizes UI libraries by category, stack, and use case. Search from the homepage, then compare matching libraries in the directory.

• Search by name, keyword, category, stack, or use case.
• Search by component name, and jump straight to that component's official docs.
• Filter libraries without leaving the directory.
• Save useful libraries locally.
• Open the official website or documentation from each listing.
• Contribute missing libraries through a focused pull request.

Col catalogs libraries. Libraries can also list the components they document, so you can search by component name — but that list is partial and grows by contribution, so a component missing from Col is not necessarily missing from the library. Col never infers a component from a library's generic tags.

Run it locally

Requirements: Node.js 20.9+ and npm.

git clone https://github.com/screen-gd/Col.git
cd Col
npm install
npm run dev

Open the local URL printed in the terminal (usually http://localhost:3000).

Before opening a pull request:

npm run typecheck
npm test
npm run build

Request something

Use the matching issue form. One focused request per issue makes discussion and review easier.

Request a library

Open a library request when a useful UI library is missing.

Include:

• the library name and official URL;
• what it provides and who it helps;
• its supported stacks;
• the closest Col category and use cases;
• confirmation that it is maintained and publicly accessible.

Search existing libraries, issues, and pull requests first.

Request a feature

Open a feature request for improvements to discovery, comparison, contribution, accessibility, or the library detail experience.

Explain the problem before proposing the interface. Include the expected outcome and any useful references.

Report a bug

Open a bug report with:

• the page or action that failed;
• exact reproduction steps;
• expected and actual behavior;
• browser, operating system, and viewport;
• screenshots, recordings, or console errors when relevant.

Do not include secrets, tokens, private URLs, or personal information.

Add a library with a pull request

Library-only pull requests should be small and should not redesign unrelated parts of the site.

1. Fork the repository and create a focused branch.
2. Add one entry to data/libraries.ts.
3. Reuse the existing category, stack, and use-case values when possible.
4. Keep the description factual and short.
5. Confirm the URL points to the official project.
6. If you add components, verify each one against the library's own docs in data/components.ts.
7. Run npm run build.
8. Open a pull request using the provided template.

{
  name: "Library name",
  slug: "library-name",
  description: "A factual one-sentence description of what the library provides.",
  url: "https://library.example",
  category: "Component Library",
  stacks: ["React", "TypeScript"],
  useCases: ["Rapid Prototyping"],
  tags: ["accessible", "copy paste"],
}

The slug must be unique, lowercase, and kebab-case. See CONTRIBUTING.md for the full checklist.

Adding components

Components live in data/components.ts, keyed by the owning library's slug, so searching "date picker" or "stroke text" finds the libraries that document it and links straight to that component's page.

"library-slug": [
  { name: "Date Picker", aliases: ["datepicker"], url: "https://library.example/docs/components/date-picker" },
],

• name should be spelled the way the library documents it, for example Date Picker.
• aliases are optional extra search terms for what people actually type, such as cmdk for a command palette. Keep them to real search terms, not synonyms for the rest of the index.
• url must be the canonical documentation page for that exact component, on the same domain as the library, and must not be a setup or marketing page.

Coverage is partial and grows by contribution, so add a handful you have checked rather than a long unverified list. Col states this plainly in the UI, so a short accurate list beats a long speculative one.

Dedicated library pages

Each library will have a dedicated Col page with:

• a clear overview and best-fit use cases;
• supported stacks and key capabilities;
• official documentation, repository, and installation links;
• useful comparisons and alternatives;
• a copyable setup prompt for coding agents.

Agent setup prompt

Library pages will provide a prompt based on this structure:

Help me add [LIBRARY] to my project.

Project context:
- Framework: [FRAMEWORK]
- Language: [LANGUAGE]
- Styling: [STYLING SYSTEM]
- Package manager: [PACKAGE MANAGER]

Use the current official [LIBRARY] documentation. Inspect the existing project before changing files. Install only the required packages, follow the project's established patterns, preserve accessibility, and avoid replacing unrelated code.

After implementation:
1. Summarize the files changed.
2. Explain any configuration added.
3. Run the project's type-check and build commands.
4. Call out any manual setup still required.

When contributing a future detail page, keep the prompt specific to that library and link every installation claim to official documentation.

Project structure

app/                  Routes, layout, and global styles
components/           Search, filters, cards, header, and shared UI
data/libraries.ts     The curated library registry
data/components.ts    Verified components, keyed by library slug
data/library-details/ Per-library detail pages and metadata
public/brand/         Col brand assets
public/hero-logos/    Library artwork used by the homepage
.github/              Issue forms and pull request guidance

UI components

Application controls use the components in components/ui. Use the existing Button, Input, Tabs, and DropdownMenu before adding another control. Keep product-specific layout and behavior in components/, and keep visual variants in components/ui/ when the standard component does not cover them.

components.json configures shadcn/ui. The components are owned by this repository and may use Radix primitives internally for keyboard and accessibility behavior. Theme colors for those components live in app/globals.css.

Built with

Next.js · React · TypeScript · Tailwind CSS · shadcn/ui · Radix UI · Lucide

Community

Be clear, constructive, and respectful. Contributions are welcome whether you are adding a library, improving metadata, fixing a bug, or making discovery easier.

Col is licensed under the MIT License.

Find better tools. Build better interfaces.