/

Lukacho: Six Components and What the Tail Looks Like

Small, personal, published without a marketing site, and occasionally containing exactly the component you were about to write.

Serafim Korablev
Serafim Korablev
@korablev

Six components, one of them taken far more than the rest. Lukacho is about as small as a published set gets, and it is a useful example of what the tail of the ecosystem actually looks like: a handful of pieces someone built for their own work and published because there was no reason not to.

The components

Marquee is the one people find, described by its author as useful for showcasing comments or technologies. The marquee guide covers the technique - two duplicated tracks and a keyframe - and the obligations that come with anything that moves.

Image Swiper is the touch gallery, Tiles is the grid background, and Custom Cursor and Figma Cursor are pointer replacements, which the cursor guide treats as the more demanding half of that family: the native cursor carries meaning that a replacement has to reproduce.

Copy to clipboard is the small utility, and the copy button guide lists its three failure modes, of which the silent one is the state change nobody announces.

What the tail is

Most writing about this ecosystem covers the ten registries with thousands of stars. The actual shape is a long tail of sets like this one: small, personal, published without a marketing site, and occasionally containing exactly the component you were about to write.

Two things follow, and the long-tail guide makes both in general.

Take components, not sets. A six-component registry is not a dependency and should not be treated as one; it is a place one file came from.

And the maintenance question mostly dissolves. Because add copies source rather than linking to it, a set that never ships again keeps working. What you lose is future fixes, which for a marquee is not much, and for a cursor replacement is worth thinking about since that one has real edge cases.

The three checks, one more time

Whether it reads your CSS variables. What it installs alongside itself. Whether the file name will collide with something you already have, which is the only one of the three that fails silently, per the CLI guide.

Those apply to every borrowed component regardless of who published it, and they take about a minute each.

Where else to look

The honest list, because the answer is not always us:

SourceBest forTrade-off
The registry directorySeeing the whole tail with last-commit datesOnly registries that publish an index
CSSMarquees, tiles and most of what small sets containYou write them
A large registryA second option when the first nearly fitsSearch it rather than browse it
21stSmall sets alongside the large ones, searchable togetherQuality varies by author, so preview before you take it

Taking one

Every component page has a live preview and the code. Installing goes through the shadcn CLI against our registry:

bash

That key comes from your 21st account, and installs require a membership. Set API_KEY_21ST once in your shell and the command works for anything in the catalogue.

Browse the registry directory →

Frequently asked

Is it safe to use a six-component registry?
Yes, because add copies source rather than linking to it, so a set that never ships again keeps working. What you lose is future fixes, which matters little for a marquee and more for something with real edge cases such as a cursor replacement.
What does the long tail of this ecosystem look like?
Sets like this: small, personal, published without a marketing site, and occasionally containing exactly the component you were about to write. Most writing covers the ten registries with thousands of stars, which distorts the picture.
Should you adopt a small registry?
No, take components from it. A six-component set is not a dependency and treating it as one imports a maintenance question that does not apply. It is a place one file came from, and that file is yours afterwards.
What checks apply to any borrowed component?
Whether it reads your CSS variables, what it installs alongside itself, and whether its file name will collide with something you already have. The last is the only one that fails silently, which is why reading the diff after every install is the habit that matters.

Published

Aug 21, 2026

Read time

3 min

Tags

ComparisonRegistriesReactCommunity

Share