Install Wensity in under a minute.

Wensity ships as a CLI. You don't install a runtime package. The CLI copies real source files into your project, so the code is yours to read, edit, and refactor.

Most component libraries hide behind a versioned npm package. That works until the day you need to bend a component to fit your product, and you're fighting prop APIs, theme contexts and breaking changes shipped on a Tuesday afternoon. Wensity inverts the model: the CLI lands the actual .tsx files in your repo, your linter sees them, your designer can tweak them, and there's no upstream to fight when a redesign happens.

You should be done with the four steps below in well under a minute. After that, every component is a single command away.

Requirements

Wensity is built for modern React. We test against Next.js 14+ (App Router or Pages), Vite 5+, Remix and Astro, anywhere React + Tailwind v4 are wired up.

React 18.2+
TypeScript 5+
Tailwind v4

1. Initialise Wensity in your project

Run the init command in the root of any Next.js or Vite project. It writes a wensity.json registry and a small utils file (cn helper).

terminal
$npx wensity init

The init command is fully non-destructive. If a wensity.json already exists it will skip; if a cn() helper is already in place it'll keep yours. The goal of step one is to give the CLI a map of where to write files. Nothing more.

2. Install the runtime peers

Wensity components are zero-runtime. They only rely on libraries you almost certainly already have.

terminal
$npm install framer-motion clsx tailwind-merge @radix-ui/react-slot

These four packages cover roughly 95% of components in the library. A handful of motion-heavy components also pull in gsap or @gsap/react. The CLI will tell you exactly which peers a given component needs at install time.

3. Add your first component

The CLI fetches the source for the component you name and drops it into src/components. You own the code from that moment forward.

terminal
$npx wensity add liquid-multimodal-input

Every add command is idempotent and safe to re-run. If a component file already exists, wensity add stops instead of overwriting it. Use wensity update <slug> when you intentionally want to replace the local copy, then review the git diff.

4. Use it anywhere

Import like any local component. No providers, no context, no global config. Just JSX.

Components are typed, side-effect free, and never reach for global state. Drop them in a server component, a client island, a modal, anywhere.

Usage example

app/page.tsx
import { LiquidMultimodalInput } from "@/components/wensity/liquid-multimodal-input";
export default function Page() {
return (
<main className="grid place-items-center min-h-screen">
<LiquidMultimodalInput placeholder="Ask anything…" />
</main>
);
}

The default install path is src/components/wensity, but you can change it in wensity.json and re-run any add command. The CLI follows the config.

Troubleshooting

Three things go wrong more often than the rest. If something isn't rendering correctly, work through this list before anything else.

Tokens aren't applying

The component imports our CSS variables (--color-chili-500, --surface, --border, etc). If you see un-styled buttons or missing colors, your global stylesheet is missing the @theme inline block. Hop to the Theming guide and paste the tokens once.

Animations look stiff

Wensity components are tuned against Framer Motion 12. If you're on an older major you'll see jitter on layout-animated components. Bump to ^12 and the spring physics fall back into place.

Server / client boundary errors

Most interactive components start with a 'use client' directive at the top of the file. If you see hydration errors, check that your wrapper page or layout doesn't accidentally re-mark the component server-only.

What's next

With the CLI wired up, the rest of the library is one command away. Most teams start by browsing the gallery, picking a single hero or input component, and shipping within an hour.