uselayouts: animated React components you install with the Shadcn CLI

What the library is, and the argument behind it

uselayouts is described as a micro-interaction UI library for professionals, providing free premium animated React components and micro-interactions built with Framer Motion and Tailwind CSS, and it is designed to integrate with Shadcn UI. The README states the premise directly. People do not fall in love with components, they fall in love with how something feels, and uselayouts focuses on the fine details of interaction. The feature list breaks that down into premium animations built with Framer Motion for smooth transitions, Shadcn compatibility, a focus on micro-interactions, and copy and paste integration into any React project. Two further properties are listed under Features: accessible, built on top of accessible primitives, and customizable, fully stylable with Tailwind CSS classes. The project is MIT licensed, written in TypeScript, with the homepage at uselayouts.com, and it is part of the Vercel OSS Program according to the badge in the README.

The installation model: a registry, not a dependency

The way components reach your project is the most consequential design decision here, and it is the Shadcn model rather than the npm model. You add a component with the Shadcn CLI, pointing it at a URL in the uselayouts registry.

npx shadcn@latest add https://uselayouts.com/r/3d-book

You replace 3d-book with any component name from the documentation. The consequences are worth spelling out. The component source ends up inside your repository, so you own it from that point and can edit it freely, which is the same bargain Shadcn itself offers and the reason Shadcn-compatible libraries are popular. The second consequence is that there is no version pin. You are not depending on a package that gets upgraded under you, you are copying a snapshot of a component, and the update story is a diff you apply yourself. That is the trade: freedom and no maintenance help in exchange for no automatic breakage.

Running the documentation site locally

The README documents how to work on the project itself, which is a Next.js site with a component registry behind it. The sequence is clone, install, run.

   git clone https://github.com/iurvish/uselayouts.git

   yarn install

   yarn dev

There is a separate build step for the registry itself, which is the artifact the Shadcn CLI actually reads.

yarn build:registry

The package.json confirms what the site is made of. The scripts show next dev for development, a build that runs the registry build and then next build, next start for serving, eslint for linting, fumadocs-mdx for the documentation, tsx scripts/build-registry.mts for the registry build, and tsx scripts/push-auth-emails.mts for pushing auth emails, with fumadocs-mdx also running as a postinstall step. The dependencies list explains the stack: Framer Motion and Tailwind for the animation and styling side, Radix UI collapsible, Base UI, floating-ui and cmdk among the accessible building blocks, class-variance-authority and clsx and cn for class handling, Fumadocs core and MDX for the documentation site, and Supabase for auth and metadata, with Vercel analytics and a payments dependency alongside.

The registry files that make the CLI work

The repository layout is what tells you how a Shadcn registry is actually assembled, and it is worth understanding if you want to add your own components to the same distribution. There is a registry.json and a registry/ directory, plus components.json, which is the Shadcn configuration file that tells the CLI where your components live and how they should be styled. The components/ directory holds the component sources themselves, and the content/ directory holds the documentation content, with mdx-components.tsx wiring MDX into the React tree. The scripts/ directory contains the build-registry script that the package.json calls, and the source.config.ts file configures the content source. There are also hooks/, lib/, types/, styles/ and public/ directories, an app/ directory for the Next.js routes, a middleware.ts, and a supabase/ directory.

The environment file shows what the site actually depends on

The .env.example file is more informative than it looks, because it names the services the documentation site needs. Cloudflare R2 handles media uploads for the admin browse feature and is marked as local and dev only, with the account id, access key, secret key, bucket and a public CDN base URL expected with no trailing slash. Supabase is used for auth, component metadata and copy events, with separate public variables for the URL and the publishable key, a commented out anon key alternative, and a server only service role key for admin metadata sync from filesystem writes. A personal access token is listed as well, and the comment says it is used only by the npm run push:auth-emails script. The pattern is the usual one for a Next.js site with a component registry: object storage for media, a hosted Postgres with auth for the metadata and the copy to clipboard telemetry, and a service role key kept on the server.

The limits, and what Shadcn itself already gives you

Three constraints are worth naming. The first is the stack dependency. The components are built with Framer Motion and Tailwind CSS and assume a Shadcn UI setup, so in a project without Tailwind, or without the Shadcn convention, you are not adding a component, you are porting one. The second is that copying the source means you own the bugs, the accessibility gaps and the updates. The README claims the components are built on accessible primitives, which is the right foundation, but the documentation does not say which primitives or what the keyboard and screen reader behaviour of each animation is, and an animated component that traps focus or announces badly is a regression you will only find in testing. The third is the absence of a release story. The package is private with version 0.1.0, the repository has no GitHub releases, and the only version of a component you get is whatever the registry serves at the moment you run the CLI. The alternative to weigh is the plain Shadcn approach of writing the animation yourself with Framer Motion directly, which leaves you with no third party code in the bundle at all.

Maintenance, licensing and the shape of the project

The repository is not archived, and the last push was on 2026-10-19, so the registry and the site are being worked on continuously, which is the model a registry based distribution needs. The licence is MIT, and the README states it directly, crediting Urvish Mali as the author with a link to the Twitter account @0xUrvish. The package.json agrees, with the author field naming Urvish Mali and the same handle. The remaining tree entries tell you how the site is operated rather than how the components are authored: an .env.example, eslint.config.mjs for linting, postcss.config.mjs, next.config.mjs, a cli.json alongside components.json, a registry.json, a scripts/ directory, skills-lock.json, and both a package-lock.json and a yarn.lock, which reflects a project that has used more than one package manager. The community links are the website, the GitHub repository and the author's account, with the component names and their documentation served from uselayouts.com.

Editorial conclusion

Adopt uselayouts if you already use Shadcn UI and Tailwind CSS and want a handful of polished animated components without pulling in a whole component library. Do not adopt it if your project is not on React with Tailwind, since the components are built on Framer Motion and the Shadcn registry format. Before you install anything, read the registry entry for the specific component you want, because the CLI copies source into your project and the maintenance burden then sits with you, and check the accessibility note, since the README claims the components are built on accessible primitives without detailing which ones.

Frequently asked questions

Official sources

1. Issues
2. iurvish/uselayouts on GitHub
3. License: MIT
4. Project website
5. README