Next.js Alert — Server-Rendered Component, Zero JS

Drivn installs through a tiny CLI that writes component source files directly into your repository — there is no runtime npm package and no version lock to upgrade. Open a terminal in the root of your Next.js 16 project and run npx drivn add alert. The CLI prompts for your install directory (defaulting to src/components/ui/) and copies the Alert source file. If you want to ship icons, it also flags lucide-react as a peer — install it once and every Drivn component that renders an icon will share it. The CLI reference documents every flag, including how to target a custom path or add several components at once. After install you own the file; future Drivn releases will not overwrite it, and you can edit the internals without forking a package. Commit the change so you have a clean baseline before customizing.

App Router pages are server components by default, which means any client-side hook inside them triggers an error at build time. Most toast and alert libraries sidestep this by marking their root as a client component, forcing the host page to also become client or to wrap the component in a client boundary. Drivn's Alert has no such requirement. It contains no useState, no useEffect, and no 'use client' directive — the component is a pure function that maps its props to a div with Tailwind classes. Drop it anywhere in a server tree and Next.js streams it as part of the HTML response, with no JavaScript shipped for the alert itself. The installation guide covers project bootstrapping; the Alert docs list every prop.

A static alert is rarely what production pages ship. You usually want the variant, title, and body to reflect something real — a trial countdown read from the database, a deployment status fetched from an API, a form-submission flash message passed through a cookie. Because the Alert runs as a server component, you can await any data source directly in the page and pass the result into the component. No useEffect, no client-side fetch, no loading spinner. The HTML that ships to the browser already carries the correct variant and copy. Combine this with Next.js fetch caching or revalidateTag and your alerts can stay accurate without a single line of client code.

The Alert exposes an icon prop typed as React.ComponentType<{ className?: string }> | React.ReactElement — pass either a component reference or a ready-made element. Passing the component (icon={Info}) is cleaner and lets the Alert decide when to render and size it. Because lucide-react ships tree-shakable named exports, each imported icon adds only its own SVG to your bundle, typically one to two kilobytes. The icon appears in a flex-shrink-0 mt-0.5 wrapper next to the title and children, so vertical rhythm stays consistent whether the alert is a single line or a three-line paragraph. For the full icon catalog, browse the lucide-react site and import only what you use. The Alert examples page shows seven icon pairings side by side.

Every visual decision in the Alert lives in a co-located styles object at the top of src/components/ui/alert.tsx, above the component itself. Four variant strings map to HSL tokens — bg-accent/50 for default, bg-info/10 for info, bg-success/10 for success, bg-destructive/10 for destructive — each paired with a matching border and text color. Two further keys handle the inner layout: title for the bold heading and description for the body's opacity-90. Retuning colors, widening the padding, or adding a fifth variant all happen inside this one object, and because the variant prop is typed as keyof typeof styles.variants, a new key shows up in autocomplete the moment you add it. Projects scaffolded with npx drivn@latest create already declare these tokens in Tailwind v4's inline @theme block, so light and dark mode track without extra work. Bringing Alert into an existing codebase that names its tokens differently? This object is the only place you need to touch. The theming page lists every Drivn token and its default HSL value.