# cuicui: copy-paste animated components, and the project that replaced them

> cuicui was a collection of animated React components built with TypeScript, Tailwind CSS and Framer Motion, shipped in the copy-paste style, where you take the source into your own repository and own it. The readme now says the author maintains the components in a successor project called Control UI, which is the first thing to read before you install anything.

**damien-schneider/cuicui** — Simplify your UI with clean, copy-paste components that minimize JavaScript, maximize CSS, spark creativity, and empower you with code you fully own and understand.

- Repository: https://github.com/damien-schneider/cuicui
- Website: https://cuicui.day
- Stars: 977 · Forks: 52
- Language: TypeScript
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/damien-schneider-cuicui

## The readme now points somewhere else

The most useful thing in this repository is a short section titled Control UI, and it tells you where the work went.

The components the author maintains today live in Control UI, which is described as shadcn-compatible React components on Base UI and Tailwind CSS, with skins you can switch, from Refined to Windows 98. The readme is explicit that it is the same idea as cuicui, copy the source into your project and own it.

So the repository you are looking at is the earlier iteration of a component library whose model has not changed, only its name and its base layer. The base layer is the interesting change. A component library built on a headless component system and a Tailwind theme, with interchangeable skins, is a different proposition from one built on Framer Motion primitives, because the appearance stops being part of the component and becomes a layer you can swap.

That is a significant architectural bet for a copy-paste library, and it is a good one to be aware of before you copy anything.

The installation of the successor is a single command through the shadcn CLI, which is the registry protocol that has become the standard for this style of library:

```bash
npx shadcn@latest add https://control-ui.dev/r/all.json
```

A registry manifest, fetched by the tooling you may already have, is a much better delivery mechanism for copy-paste components than a package, because the point is that the code ends up in your repository rather than in your dependency tree.

## The idea: own the code, understand it

The project description is the argument, and it is worth reading as a design position rather than as marketing.

The components are described as open-source animated components built with React, TypeScript, Tailwind CSS and Framer Motion, one hundred percent open source and customizable, that can be copy-pasted directly into your codebase. The repository description puts it more bluntly: clean, copy-paste components that minimise JavaScript and maximise CSS, with code you fully own and understand.

That is a real alternative to a component library, and the trade-offs are worth being clear about.

What you gain is ownership. The component is in your repository, so you can change it without fighting a package's abstractions, you can read it to understand what it does, and you can delete the parts you do not use. There is no runtime dependency, no version conflict to resolve and no upstream breaking change to absorb.

What you give up is maintenance. Nobody else is going to fix the bug in the tooltip you copied two years ago, and if the library is updated, your copy does not follow. The copy-paste model also has a discovery problem, since there is no package to install and no version to pin, so the components you use are the ones you copied when you needed them.

The JavaScript versus CSS point is the other half of the design. The ambition is that most of the visual behaviour is expressed in CSS and Tailwind utilities, with Framer Motion used for the parts that genuinely need a JavaScript animation loop. That is the right instinct for performance and for the accessibility of reduced motion preferences, though the balance is a per-component decision rather than a rule.

## A Turbo and pnpm monorepo with a website app

The repository layout is a modern JavaScript monorepo, and it tells you how the project is organised.

There is an apps directory, a packages directory, a scripts directory, and configuration for Turbo, for pnpm workspaces, and for Biome, with a package manager pin and a Node engine requirement. The root package is private, and its name is cuicui.

The scripts are all Turbo passthroughs, which is the standard way to orchestrate a monorepo: a build, a dev, a lint, a start, a type-check, a clean, and a test with a watch variant. Turbo then handles the dependency graph and caching, so a change in one package only rebuilds what depends on it.

The toolchain is pinned tightly, which is a deliberate choice in a repository where the build has to work the same on every machine. The package manager is pinned to a specific major of pnpm, Node 22 or later is required, Turbo is at version 2, Vitest is at 2.0.5, the React plugin for Vite is at 4.3.1 and Biome is at 1.9.2.

The apps directory almost certainly holds the website, since the readme links a project site and a banner image with a path inside that directory, and the packages directory holds the component library itself, which the build scripts treat separately. The test setup is a workspace file, so tests are configured per package rather than globally, which is what a component library needs since each component is a small package with its own cases.

## A justfile for the chores a monorepo accumulates

There is a justfile at the root, and it is a good example of what a task runner is for in a repository that already has a build tool.

Turbo handles the build graph, so the justfile handles the things a build tool does not. There is a recipe that lists all the dependencies in the monorepo, including the dependencies of the dependencies, and writes them to a file, which is how you find out what pulled in a package you have never heard of. There is a clean recipe that runs the Turbo clean and then a cleanup script in the scripts directory, and a reset recipe that forces a recursive install to reset the lockfile in the root and every subfolder.

The build recipes cover the usual variations, including one that builds only the packages directory, one that builds only the UI package with a working directory override, and one that runs the Turbo build with the graph option to produce an image of the build process, which is a nice touch for a project with this many packages.

The formatting recipes are all Biome, and they come in escalating versions: a check, a check limited to errors, a write that applies the safe suggestions, and a write variant that also applies the unsafe ones. The last one is named as such, which is the right way to expose it, since applying unsafe fixes automatically is a choice a human should make deliberately.

```bash
pnpm biome check --write
```

The default recipe just lists the available commands, with a heading explaining what the list is. That is friendlier than a task runner that greets you with an error.

## Licence, contributing and the shape of the project

The administrative side is minimal and conventional.

The project is MIT licensed, with the licence file at the root, and the readme links to it. There is a contribute document linked from the readme for people who want to work on the codebase, a second contributing document, a code of conduct, and an issue template flow with a page for creating an issue.

The contribution guidance in the readme is short and splits the audience in two: you can contribute by just writing issues, or by contributing to the codebase. That is a deliberate widening of the contribution surface, and for a component library it is the right instinct, since the most valuable feedback about a copy-paste component is often about how it behaved in a real application rather than about the component itself.

The repository also carries an editor configuration, a Node version file, a Visual Studio Code directory, and a continuous integration workflow directory, and the top level has a commit history chart badge and a repository analytics embed.

What the repository does not have is any package published under the cuicui name that you would add as a dependency. The readme does not offer a install command for the cuicui components themselves, only for the successor registry, which is consistent with the copy-paste model: there is nothing to install, you take the source.

That is worth stating plainly for anyone arriving from a search result looking for a package. The deliverable here is code you read and copy, and the maintainable version of that code now lives in the other project.

## Release history and what it tells you

The release history is short and slows down, and that is consistent with the readme pointing elsewhere.

Version 0.4.9 was released on 2025-03-15 and version 0.4.10 the next day, on 2025-03-16, and then version 0.4.11 came on 2026-01-20. The last push to the repository was on 2026-10-11, so the tree is not abandoned, but the tagged releases are sparse.

The 0.x version number is a signal in its own right. For a library that people copy into their projects, the version number barely matters, because you are not depending on it, which means the versioning scheme was never going to be used to communicate compatibility. The real compatibility story is the source you copied and the date you copied it.

The most useful thing about the release history here is negative information. It tells you that the cuicui package line is not where new components are appearing, which is exactly what the Control UI section says, and it stops you from starting a new project on a component set that is unlikely to gain new entries.

So the sensible order of operations is to look at Control UI first, since it is the maintained line and it has a registry, a shadcn-compatible install and a Base UI foundation, and to treat cuicui as the earlier experiment whose model of copy-paste ownership is now applied to a more modular design. If you do want the older components, the source is here, it is MIT licensed, and you can read every line of what you take.

## Conclusion

cuicui is worth reading if you want the copy-paste component model in React with animation, because the ideas are sound and the source is yours to keep. It is not where you should start today, since the author says the components they maintain now live in Control UI, and the package releases here have not moved in a while. Before you build on either project, look at Control UI, decide whether the shadcn-compatible registry model works for your project, and read the component source before copying it, since copy-paste libraries are only as good as the code you take.

## FAQ

### Where are the cuicui components maintained now?

The readme says the components the author maintains today live in Control UI, a separate project with shadcn-compatible React components on Base UI and Tailwind CSS, with switchable skins. The readme describes it as the same idea as cuicui, copying the source into your project and owning it, and it is installed with the shadcn CLI using a registry manifest.

### How do I install the Control UI components?

With a single command that fetches the registry manifest through the shadcn CLI, run as npx shadcn@latest add with the URL of the registry's all.json file. Because the components are copy-pasted, that command writes the source into your project rather than adding a dependency.

### What tools does the cuicui monorepo use?

Turborepo orchestrates the build, dev, lint, type-check and test scripts across the workspace, pnpm manages the packages with the package manager pinned and Node 22 required, Biome handles formatting and linting, and Vitest runs the tests with a workspace configuration.

### What is the justfile in the cuicui repository for?

It handles the chores a build tool does not: listing all dependencies in the monorepo including transitive ones, cleaning the repository, resetting the lockfile, running the build for only the packages or only the UI package, generating an image of the build graph, and running Biome in check or write mode.

## Sources

- [damien-schneider/cuicui on GitHub](https://github.com/damien-schneider/cuicui)
- [License: MIT](https://github.com/damien-schneider/cuicui/blob/main/LICENSE)
- [Project website](https://cuicui.day)
- [README](https://github.com/damien-schneider/cuicui/blob/main/README.md)
- [Releases](https://github.com/damien-schneider/cuicui/releases)

---

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