# Componentry: React components you copy in rather than install

> Componentry distributes animated React and Tailwind components as registry payloads added with the shadcn CLI, so the code lands in your repository and you own it. There are no published releases, and two components pull in GSAP under separate terms.

**harshjdhv/componentry** — Animated, production-ready UI components. Built the way real products need them.

- Repository: https://github.com/harshjdhv/componentry
- Website: https://componentry.dev
- Stars: 616 · Forks: 41
- Language: TypeScript
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/harshjdhv-componentry

## Copy and paste instead of a dependency

Componentry is a collection of interactive UI components built with React and Tailwind CSS, and the distribution model is the point. The README is explicit about it: copy and paste, not a dependency, you own the code. The project description puts the same idea more bluntly, with components that are animated and production ready, built the way real products need them.

That model has concrete consequences. There is no version of Componentry in your package.json, so there is no version conflict, no peer dependency negotiation and no major version bump that breaks your build. It also means there is no automatic upgrade path, because the code now lives in your repository and only you can change it. A design tweak from the upstream project reaches you when you go and copy it.

The feature list explains what the components do. Interactive means cursor-following effects, 3D transforms and smooth animations, built with Framer Motion. Customizable means the styling is Tailwind, so you change a class rather than fight a theme object. All components support light and dark modes, and everything is written in TypeScript with full typing.

On accessibility the README is careful, and you should read it carefully too. The claim is accessible foundations, with native controls and component specific keyboard and motion support, and the instruction that follows is to validate accessibility in your application. Copying a component does not copy a conformance claim, and the audit remains yours.

## Adding a component is one shadcn CLI call

The install path reuses the shadcn CLI, which is how the components are transferred into your project.

```bash
npx shadcn@latest add @componentry/magnetic-dock
```

That command fetches the component payload, writes the source into your codebase, and adds the dependencies the component needs. The registry entry is named, in this case @componentry/magnetic-dock, and the same mechanism presumably serves the rest of the catalogue.

The registry is a real part of the project's design, not just a packaging detail. The package.json contains registry scripts that build and verify it.

```json
    "registry:generate": "node scripts/generate-registry.js --all && node scripts/build-blocks-registry.js",
    "registry:check": "node scripts/generate-registry.js --check && node scripts/build-blocks-registry.js --check && node scripts/validate-registry.js",
    "test": "node --test tests/registry.test.cjs",
    "test:registry:install": "node scripts/smoke-registry.mjs",
```

The check script verifies registry freshness, dependencies and documentation coverage, and there is a separate install test that installs and typechecks representative payloads in a fresh app. That is the closest thing the project has to a test for the thing the user actually does, which is add a component to a project that has never seen it before.

The components themselves are documented on the site, with a documentation link and a components link in the header of the README.

## A Turborepo monorepo with one library package

The repository is a Turborepo monorepo managed with pnpm, and the tree is small enough to describe in one breath. The apps/ directory holds web, the documentation site built with Next.js, and packages/ holds ui, the component library, along with eslint-config and typescript-config for shared configuration. A turbo.json file holds the Turborepo configuration.

Development needs Node.js 20 or newer and pnpm 10 or newer.

```bash
# Clone the repository
git clone https://github.com/harshjdhv/componentry.git
cd componentry

# Install dependencies
pnpm install

# Start development server
pnpm dev
```

The tech stack is stated at the end of the README: Next.js 16 for the framework, Tailwind CSS 4 for styling, React 19 for components, Turborepo for build, and pnpm as the package manager. The root package.json pins the package manager at pnpm@10.4.1, requires node 20 or newer, and declares an empty dependencies list, which is consistent with a workspace that only holds its own packages.

The tree also carries agents/, scripts/, temporary/, tests/, docs/ and a .github directory, and the root version is 0.0.1 with the package marked private. That private flag is the point: the root is not something you consume, it is the place where the components are produced.

## The script list shows what is actually checked

The available scripts are documented as a table, and they describe a project that treats the registry as a tested artifact.

```
| `pnpm dev` | Start development server |
| `pnpm build` | Build all packages |
| `pnpm lint` | Run linting |
| `pnpm format` | Format code with Prettier |
| `pnpm registry:generate` | Regenerate component and block payloads |
| `pnpm registry:check` | Check registry freshness, dependencies and docs coverage |
| `pnpm test` | Run distribution regression tests |
| `pnpm typecheck` | Typecheck the web and UI workspaces |
| `pnpm test:registry:install` | Install and typecheck representative payloads in a fresh app |
```

Beyond the documented set, the package.json contains the machinery for the site itself: a script to build the blocks registry, a registry validation script, an Open Graph image generator, a screenshot script, and two scripts for preview media, one of which runs a Python script from a virtual environment at scripts/venv/bin/python and recompresses and reuploads previews.

The typecheck command runs through Turborepo across the web and UI workspaces, the unit test runs with the Node built-in test runner against tests/registry.test.cjs, and the format command is Prettier over TypeScript, TSX and Markdown.

The composition tells you where the effort goes. This is a project where the interesting work is not writing React components but keeping the registry payloads installable, documented and consistent, and the scripts are built around that.

## No releases means no upgrade path

The repository has no GitHub releases, and that is a structural fact rather than an omission. The release history of a project that ships through a registry is different from one that ships through npm. There is no version bump to consume, so there is no upgrade note to read and no semver contract to check against.

The consequence for a consumer is that you maintain the copy. When you add a component, the source lands in your tree with the dependencies it needs, and from that point the component is yours, including its bugs and its accessibility behaviour. If the upstream project later fixes something in that component, the fix arrives when you copy it again, if you notice.

The project compensates partly with tooling. The registry:check command verifies freshness, dependencies and documentation coverage, and the install test proves that a representative payload can be added to a fresh application and still typecheck. Those checks protect the publisher, and indirectly the consumer, but they do not replace a versioned release.

For teams with a dependency review process, a policy that every package in package.json has an owner and a version, this model does not fit without adaptation. The components would be vendored source under your own licence and your own review cycle, which some organisations are happy with and others are not.

## GSAP is the licensing wrinkle

The licence section has a second heading that is easy to skim past. The components themselves are MIT licensed, and the README says you are free to use them in personal and commercial projects. But there is a third-party licences section underneath, and it names two specific components.

The image-trail and layered-stack components require gsap, GSAP. If you use or redistribute those components, you are responsible for complying with GSAP's own licence terms, and the README links to the GSAP licensing page for the details.

That is a real and common pattern in the copy and paste component world. The component source under MIT is fine, but the animation engine it depends on may carry terms that are not as permissive, and the responsibility lands on whoever ships the result. Two of the components in a catalogue of this size is a small problem, but it is the kind of thing that gets discovered by a licence scanner rather than by a developer, which is the worst time.

The LICENSE file is the place to check for the full terms, and the practical advice is short. If you are copying a component into a commercial product, check whether it is one of the two that needs GSAP before you do, and read the GSAP terms at that point rather than assuming MIT covers the whole stack.

## When a component gallery is the wrong answer

The clearest case against this approach is a design system with a fixed component API. If your organisation has agreed what a Dialog looks like and how it behaves, a gallery that encourages you to paste a different implementation into each project works against that agreement. The upstream project acknowledges the model, since it lists shadcn/ui as an inspiration, and a shared registry with one canonical version of each component solves the same problem in a way that copy and paste does not.

The second case is accessibility as a hard requirement. The README says to validate accessibility in your application, which is honest, but it means the burden is on you. A component with a cursor-following effect and 3D transforms can still be a keyboard trap, a motion problem for users who have asked for reduced motion, or an unreadable contrast combination, and you will only find out by testing it.

The third case is any project where you want the upstream fixes to arrive. There is no release, so no upgrade. If the component is important enough that you would want its bugs fixed by the people who wrote it, this model is a poor fit unless you are prepared to track the repository and pull changes across by hand.

Otherwise, for a product team that wants an animated, dark mode capable, typed component today and is happy to own the code tomorrow, the arrangement is genuinely convenient.

## Conclusion

Componentry suits a React and Tailwind team that wants a well animated component it can read, edit and delete rather than a versioned dependency, and that is comfortable copying source into its own repository. It does not suit a codebase with strict dependency review rules or one that expects upgrades to arrive as a version bump, since there are no published releases and no changelog to diff. Verify first whether the components you want pull in GSAP, because image-trail and layered-stack require it and carry separate licence terms, and read the component creation guide before you change anything in the registry.

## FAQ

### How do I add a Componentry component to my project?

You use the shadcn CLI with the component's registry name, for example npx shadcn@latest add @componentry/magnetic-dock. The source is written into your repository rather than installed from a package.

### What do I need to develop Componentry locally?

Node.js 20 or newer and pnpm 10 or newer. You clone the repository, run pnpm install, and then pnpm dev to start the development server. The project uses Turborepo for monorepo management.

### Does Componentry publish versioned releases?

The repository has no GitHub releases. Components are distributed as registry payloads added through the CLI, so there is no version bump to consume and no automatic upgrade path.

### Which Componentry components need a separate licence?

The image-trail and layered-stack components require gsap. The README states that if you use or redistribute those components you are responsible for complying with GSAP's license terms, and links to the GSAP licensing page.

### How do I contribute a component to Componentry?

Fork the repository, create a feature branch, commit your changes, push the branch and open a pull request. The README points to the component creation guide for source, registry and documentation steps, and to the maintenance guide for validation commands.

## Sources

- [harshjdhv/componentry on GitHub](https://github.com/harshjdhv/componentry)
- [Issues](https://github.com/harshjdhv/componentry/issues)
- [License: MIT](https://github.com/harshjdhv/componentry/blob/main/LICENSE)
- [Project website](https://componentry.dev)
- [README](https://github.com/harshjdhv/componentry/blob/main/README.md)

---

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