Next.js Badge — Server-Rendered, Zero JS

Drivn installs through a CLI that writes component source files directly into your repository — there is no runtime npm package and nothing to keep upgrading. From the root of your Next.js 16 project run npx drivn add badge. The CLI prompts once for an install directory, defaulting to src/components/ui/, then writes badge.tsx into place. The Badge carries zero peer dependencies: it imports only React and the local cn class-merge helper, so package.json does not change and there is no icon library to add. The CLI reference documents every flag, including custom install paths and adding several components in one command. Once the file lands you own it — future Drivn releases never overwrite it, and any edit you make is permanent.

App Router pages are server components by default, and any client hook inside one fails the build. Drivn's Badge has nothing that could fail — it is a pure function with no 'use client' directive, no state, and no effect, so it renders directly inside a server page and Next.js ships the markup as static HTML with zero JavaScript for the badge itself. Pass a variant to pick one of the five styles and any children for the label. The installation guide covers project setup; the Badge docs list every prop with its type and default.

The variant prop accepts five values — default, secondary, success, outline, and destructive — each mapped to a Tailwind string in the component's styles.variants object. Four of them follow the same recipe: a token color at 15% opacity for the background, the full-strength token for the text, and a 20–30% border of the same hue. That recipe works because Drivn's colors are HSL custom properties, so opacity modifiers like bg-primary/15 resolve at the CSS level without extra tokens. The outline variant skips the tinted background entirely and reads as a quiet label. Use success for healthy states, destructive for failures, secondary for counts, and outline for metadata like version numbers. The Badge examples show all five in real layouts.

Most badges in a real app are driven by data — an order status, a deployment state, a subscription tier — fetched on the server and rendered in a table or list. Because the Badge is server-safe, the lookup from data to variant can live right next to the query, with no client boundary in between. Define a record that maps each status value to a variant name and index into it at render time. The variant prop is typed as keyof typeof styles.variants, so TypeScript verifies every value in the map against the variants that actually exist in your copy of the component — add a variant, and the map type-checks against it immediately.

Because the CLI copies the source into your repo, restyling badges is a string edit, not a theme override API. The whole visual surface lives in one styles object: base holds the pill shape — inline-flex, gap-1.5 between children, rounded-full — and variants holds the five color recipes. Add a warning variant by inserting one more key with the same opacity pattern, and the keyof typeof prop type autocompletes it across the codebase instantly. To reshape every badge at once — say square corners via rounded-md — edit base. The variant colors read the primary, secondary, success, and destructive tokens, so a rebrand through the theming page restyles every badge without touching this file.