# unlight/tailwind-components generates a link index of Tailwind snippets, not a package

> Every entry in the README points at daisyUI, Flowbite, Preline or a snippet gallery instead of showing markup, and a Puppeteer driven TypeScript program rewrites the file from those pages. Useful as a map of where existing snippets live, it offers nothing to install into a build.

**unlight/tailwind-components** — Collection of components found on the internet

- Repository: https://github.com/unlight/tailwind-components
- Stars: 2,021 · Forks: 231
- Language: TypeScript
- License: not declared
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/unlight-tailwind-components

## Every README entry links out to daisyUI, Flowbite or a snippet gallery

There is no component markup anywhere in this README. The file is a table of contents running through thirty-four top level categories, from Accordion and Alert/Notification through Timeline, and every bullet under a heading is a link to somebody else's page: daisyui.com, flowbite.com, preline.co, tailgrids.com, tailwindcomponents.com, tailwindtoolbox.com, tinywind.dev, a CodePen at codepen.io/robstinson/pen/LYZProy, and kimia-ui.vercel.app. Entries carry the component name alongside the site it came from, so a reader can see at a glance that daisyUI has an arrow icon variant and that Flowbite has a flush one. The repository description calls this a collection of components found on the internet, and that description is accurate: it is a discovery index. For someone who already knows which component they need, reading it beats guessing search terms. For someone who needs a component they can install, it points the wrong way.

## The generate script chains a JSON crawl, a README writer and remark

The pipeline is legible in the scripts of package.json. The `generate` script chains two others, and the first of them runs the fetch program with a JSON format flag:

```bash
npm run program -- --format=json
ts-node src/readme-components.ts && npm run remark:update
```

That second line is the whole build: write the file, then hand it to remark, which regenerates the table of contents through the `remark-toc` plugin configured in `.remarkrc.js`. The supporting shell step is `sh Taskfile remark_run --output`, so the table of contents is a build artifact rather than anything a maintainer typed. `components.json` sits at the repository root as the structured layer between fetch and output. Because the file is generated, whatever the fetch pass produces lands in the README unedited, and `program:x` adds an `--only=xxx` filter so a single component name can be crawled while you iterate.

## Four of the first five Accordion bullets print every name twice

Open the Accordion section and the duplication is immediate. The daisyUI bullet lists 5 names and then prints the same 5 again. The daisyUI Collapse bullet prints 12 and then 12, the Flowbite bullet prints 8 and then 8, and the Preline accordion bullet prints 10 and then 10. The fifth bullet, Preline's own Collapse page, lists 5 with no repeat at all, so this is not a deliberate house style. Two causes would produce it: the fetch pass visiting each page twice without deduplicating what it collected, or the source page now rendering every heading twice with a name parser that copies both. No script visible in package.json runs a cleanup pass between the JSON and the README, and `tscheck` only type-checks, so nothing on the visible surface would flag it.

## Component names keep the typos and emoji of their source pages

Names here are not written by a maintainer. `string-similarity` and `pluralize` sit in devDependencies beside lodash, which is the toolset page retrieval plus name matching would need, and the finished README shows exactly what that transform leaves behind. Case flips in the middle of one daisyUI list, where four entries read Accordion using radio inputs and the fifth reads Accordion Using Accordion and Join together. Another carries a mistake from upstream: the slug `simple-collapseaccording-with-alpinejs` says according where the source site meant accordion. A third keeps a fire emoji in front of every Preline component name, which a hand written list would have dropped. A curated index would have cleaned all three, and this one has not.

## First run means a ts-node script, not an installed package

package.json declares no `main`, no `bin` and no runtime dependencies, only devDependencies for the tool that builds the README. The README gives no installation command, and that matches the layout: there is nothing for a consumer to install. The first real run is a script, and the narrow one to start with isolates a single component by name.

```bash
ts-node src/program.ts --only=xxx
echo tscheck... && tsc --noEmit
```

Run the second command after touching anything under `src/`; it type-checks with `tsc --noEmit` and writes no files. For reuse, package.json records no licence field, so the repository states no grant of its own and each linked page carries its own terms instead. Copying from one of those pages is a decision about that page, not about this index.

## Puppeteer 24 sits beside 5.x type definitions in one file

The dependency list carries one skew that will surface first: puppeteer is pinned at 24.10.2 while @types/puppeteer sits at 5.4.7, so the type definitions describe an API from a much older branch. mocha 11.7.0 carries @types/mocha 10.0.10 for the same reason. Everything around them is current: remark 15.0.1, remark-cli 12.0.1, remark-toc 9.0.0, ts-node 10.9.2, typescript 5.8.3, @types/node 24.0.3, prettier 3.5.3 and expect 30.0.2, spread across nineteen devDependencies. Because puppeteer belongs to the crawl rather than to anything a consumer would run, that skew is a contributor problem rather than an adoption one. The last push was on 2026-10-04, so the file is still moving.

## Four mocha scripts differ only by watch and inspector flags

Thirteen scripts sit in package.json and four of them are the same command with different switches. The base run is `mocha -r ts-node/register --no-timeouts src/**/*.spec.ts`, shared by test:r and, with watch flags appended, by test:w. test:d adds `node --inspect` so a debugger can attach, and test:brk uses `--inspect-brk` to stop before the first line. Switching mocha's timeout off is a deliberate choice here and a coherent one for specs that drive a real browser, but it also turns a slow or unreachable page into a run that never finishes rather than a test that fails. With ts-node loading the specs and the tree rooted at `src/`, the suite needs the entire crawl toolchain present before it can say anything useful.

## daisyUI, Flowbite and Preline are the installable alternative

A reader who wants components they can install already has the shortlist inside this README. daisyUI, Flowbite, Preline, TailGrids and tinywind each publish their own component galleries with copy and paste markup, and this index links straight into them. The difference in approach is the whole argument. Here a component is a name plus a URL, and the code lives on a third party site that can change its markup, change its address or disappear, none of which the index would notice until the next crawl. A library gives you a versioned package installed through your package manager and updated when a change ships, while every entry here is frozen at the Tailwind generation its author was using, and this README records no version for any of them. One trap deserves naming: the repository is called tailwind-components while many of its links point to tailwindcomponents.com, a separate gallery with its own catalogue, and the two names collide often enough to send a reader to the wrong site.

## Conclusion

Adopt it as a bookmark, not as a dependency. The index is a fast map of where existing Tailwind snippets already live, which helps when you know the component you want and only need to find it. A team that needs markup it can install, version and upgrade will do better with one of the libraries named in those links. Before trusting anything you find, open the source page yourself, because this repository keeps no copy of the code it points at, no Tailwind version for any entry, and no test that checks a link still resolves.

## FAQ

### Is unlight/tailwind-components a component library I can install?

No. The README is a list of links to snippets hosted on other sites, and package.json declares no `main` and no bin, with nothing but devDependencies for the tool that builds the file.

### How do I regenerate the README after changing the crawler?

Run the two scripts that `generate` chains, starting with `npm run program -- --format=json` and then `ts-node src/readme-components.ts && npm run remark:update`. The remark step rebuilds the table of contents, so hand edits to that list are overwritten on the next run.

### Can I reuse the components this index points to?

package.json records no licence field, so the repository grants nothing itself. Each linked page carries its own terms, and the index keeps no copy of the code, so take the licence from the site a snippet came from.

### Why do some component names appear twice in the Accordion section?

Four of the first five bullets under Accordion repeat each name once, printing 5 then 5 for the daisyUI page, 12 then 12 for the daisyUI Collapse page, 8 then 8 for Flowbite and 10 then 10 for Preline. No visible script deduplicates between the JSON output and the README writer.

### How current is the index?

The last push was on 2026-10-04 and the repository is not archived, with no GitHub releases to track versions against. Because the README is generated, what matters is whether the crawl still reaches the linked pages rather than when the file was last committed.

## Sources

- [Issues](https://github.com/unlight/tailwind-components/issues)
- [README](https://github.com/unlight/tailwind-components/blob/master/README.md)
- [unlight/tailwind-components on GitHub](https://github.com/unlight/tailwind-components)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unlight-tailwind-components