Release notes

Lantern Fire v0.3.0 is an analytics release. Charts are now a first-class part of the design system, not a one-off you wire up per project. Forty-two chart recipes ship across four families, all themed against the Lantern token palette, all opt-in by family, all ready to drop into a dashboard, report, or internal tool.

Install:

npm install @lantern-product/ui@0.3.0

Docs: design.lantern.codes/charts

Why metrics matter for Lantern

The work happening across Lantern is increasingly metrics-shaped — engagement loops, operator dashboards, customer-facing analytics, internal back-office views. Until now, every team that needed a chart reached for raw Recharts or Chart.js, picked their own colors, designed their own tooltip and legend chrome, and ended up with surfaces that felt bolted-on instead of native to the design language.

This release closes that gap. The same way Card, Table, and Dialog are reusable surfaces with consistent affordances, ChartLineInteractive, ChartBarStacked, and ChartPieDonutText are now reusable visualizations with consistent palette, motion, and chrome. A dashboard built on Lantern Fire reads as a dashboard built at Lantern — not "an app, plus a charts library."

Four families, 42 recipes

Family	Subpath	Variants
Area	@lantern-product/ui/charts/area	10
Bar	@lantern-product/ui/charts/bar	10
Line	@lantern-product/ui/charts/line	10
Pie	@lantern-product/ui/charts/pie	11

Each family covers the full range of analytical use cases:

• Area — simple, linear, step, stacked, stacked-expand, gradient, legend, axes, icons, interactive (date-range selector over 3 months of daily data)
• Bar — default, horizontal, multiple, stacked + legend, label, custom label, mixed (per-bar colors), active (highlighted sector), negative (split positive/negative), interactive (metric switcher)
• Line — default, linear, step, multiple, dots, dots-colors, dots-custom (icon markers), label, custom label, interactive
• Pie — simple, no-separator, label, custom label, label-list, legend, donut, donut-active, donut-text (centered total), stacked (concentric), interactive (Select-driven active sector)

Every recipe themes its series through --chart-1 through --chart-5 — the same Lantern OKLCH chart tokens that appear on the /tokens page. Light and dark mode swap palettes automatically. No per-chart color picking, no theme drift between dashboards.

Opt-in, family-by-family

Recharts is not cheap (50-150 KB per family). To keep that cost off apps that don't need every chart type, each family ships as its own subpath bundle:

import { ChartLineInteractive } from "@lantern-product/ui/charts/line";
import { ChartPieDonutText } from "@lantern-product/ui/charts/pie";

An app that uses only line charts pays for only the line bundle. An app that needs all four families pays for all four. The main @lantern-product/ui entry remains Recharts-free — Button, Card, Table, etc. import costs are unchanged.

Chart primitives (the underlying ChartContainer, ChartTooltip, ChartLegend from shadcn's chart spec) continue to live at the existing @lantern-product/ui/chart subpath for projects building bespoke visualizations on top of Recharts.

Designed for dashboards and prototyping

The same vibe-coded-prototype framing from v0.1.1 holds: a ChartLineInteractive next to a Card, a Table, and a Sidebar is 80% of an internal dashboard. The dashboard looks like Lantern from the first render — themed tooltips, themed legend, themed selector chrome, dark mode out of the box, keyboard-accessible Recharts primitives underneath — so the gap between "spike" and "ship" is mostly content and data wiring.

This matters most for the kind of work Lantern is doing more of: operator tooling, customer-facing analytics views, KPI summaries inside product surfaces, and proof-of-concept dashboards that need to survive the "should we ship this?" conversation.

Docs: a new top-level Charts section

The sidebar now has its own Charts group:

• /charts — live gallery. All 42 variants on one page, grouped by family, with an anchor-pill nav to jump between sections. Modeled on the shadcn charts gallery.
• /charts/area, /charts/bar, /charts/line, /charts/pie — per-family deep dives. Each variant has a description, a code toggle showing the exact import + usage, and the live themed chart.

The Components > Data page no longer lists ChartContainer — chart primitives and chart recipes now live in their own dedicated section.

What's next

Candidates for v0.4.0:

• Radar + radial recipes to round out the gallery with the remaining shadcn chart families
• Tooltip recipes — themed tooltip patterns beyond the defaults (range tooltips, comparison tooltips, on-canvas annotations)
• Dashboard shells — example application shells composing chart families with sidebars, filters, and KPI cards, so the "dashboard in an afternoon" claim has a directly copyable starting point
• Theming presets — palette overrides for product-specific accent schemes while keeping the same chart token contract

Lantern Fire v0.2.0 is a focused identity release: the design system is now anchored on Lantern green #005042, coral has been demoted from brand primary to an accent role, and the Button API has been restructured so hierarchy is named, not implied.

Install:

npm install @lantern-product/ui@0.2.0

Docs: design.lantern.codes

Brand re-anchor

The OKLCH token scale has been rebuilt around Lantern green #005042 as the brand primary. Every semantic role downstream — --primary, --ring, --sidebar-primary, chart accents — now derives from that anchor, so the system reads as evergreen first and accent-tinted second.

Coral, which previously sat at the top of the hierarchy, has been moved into a dedicated --secondary-coral token. It's still a first-class color in the palette — it's just no longer the brand. This unlocks two things:

• Green and coral can sit next to each other in a UI without competing for attention.
• "Approve" and "Decline" pairs now have a natural semantic mapping (green / coral) instead of relying on destructive red for non-destructive decline actions.

Button hierarchy, clarified

The button variant model in 0.1.x leaned on default, outline, and secondary, which obscured the actual hierarchy. v0.2.0 makes hierarchy explicit:

• variant="primary" — filled green, high-emphasis. The single recommended action on a screen.
• variant="secondary" — outlined, low-emphasis companion to a primary action.
• variant="secondary-green" — filled green accent at the same hierarchy as primary, for distinct concurrent actions (e.g. "Approve" in an approval flow).
• variant="secondary-coral" — filled coral accent, same hierarchy slot, alternate color (e.g. "Decline").
• ghost, link, destructive, destructive-solid are unchanged.

The intent: when two same-hierarchy actions need to coexist, you reach for secondary-green and secondary-coral rather than overloading primary + destructive.

Migrating from 0.1.1

Three find-and-replace passes cover most consumers.

1. variant="default" → variant="primary"

// Before
<Button variant="default">Save</Button>
<Button>Save</Button>

// After
<Button variant="primary">Save</Button>
<Button>Save</Button>

Unspecified variant still resolves to primary via defaultVariants, so <Button>Save</Button> keeps working. Only explicit variant="default" needs to be replaced.

2. variant="outline" → variant="secondary"

// Before
<Button variant="outline">Cancel</Button>

// After
<Button variant="secondary">Cancel</Button>

This is the most common migration in the codebase. Anywhere you previously wanted "the outlined companion next to a primary action," you now use secondary directly.

3. Old filled-gray variant="secondary"

If you were using secondary because you wanted the outlined look, no change needed — that's now the meaning. If you were using it for the filled-gray pill, switch to variant="secondary-green" (filled brand) or variant="secondary-coral" (filled accent), depending on intent.

// Before — meant the outlined companion: KEEP AS-IS
<Button variant="secondary">Cancel</Button>

// Before — meant the filled accent: REPLACE
<Button variant="secondary">Approve</Button>
// After
<Button variant="secondary-green">Approve</Button>

Docs site updates

• Two new element showcases on /elements: Secondary green and Secondary coral, demonstrating the new filled accent variants alongside the existing primary and secondary showcases.
• The Button page on /components/buttons has been rewritten around the new hierarchy with a refreshed variants demo and updated migration-ready code snippets.
• "Releases" added to the marketing top nav so changelog narratives are one click from the homepage.
• The Hero3 CTA button now uses secondary-green directly, demonstrating the new filled accent in production context.

Internals

• card.tsx, carousel.tsx, alert-dialog.tsx, dialog.tsx, and pagination.tsx received small refactors as part of the token migration. No public API changes for those components.
• Button unit tests updated to cover the new variant set.

What's next

The token migration is the foundation for theming work landing in 0.3.0: surfaced theme presets, per-product accent overrides, and a tokens-only entry point for consumers who want the design language without the component library.

Lantern Fire v0.1.1 is live on npm and GitHub Packages. This is our first published beta of the shared design system.

Install:

npm install @lantern-product/ui@0.1.1

Docs: design.lantern.codes

What ships

• 52 core UI components built on Radix + shadcn/ui primitives, fully themed with OKLCH tokens and dark mode out of the box
• 128 pre-built patterns: 45 element variants (avatars, badges, buttons, dropdowns), 23 application shells (stacked, sidebar, multi-column), 25 heading patterns, and 35 layout compositions
• 3 font families (DM Sans, Poppins, IBM Plex Mono), a 9-step radius scale, 36 semantic color tokens with light/dark pairs, and 5 chart colors
• Full TypeScript, Tailwind v4, React 19, and Next.js 16 App Router support
• shadcn CLI compatible — npx shadcn add <component> works against the package directly

Why this matters for prototyping

The whole point of Lantern Fire is to make durable prototypes the default. Instead of throwaway mockups that get rebuilt from scratch, you start with production-grade components and real tokens from day one.

This is especially relevant for vibe-coded artifacts — the quick UIs you spin up with AI assistants, one-off internal tools, or proof-of-concept demos. When those are built on Lantern Fire:

• They look like the real product immediately, because they use the same tokens, fonts, and components production will use
• They survive the "should we ship this?" conversation, because the code is already structured, accessible, and themed — not duct-taped together
• They compose into real features without a rewrite. A vibe-coded prototype using our Card, Table, Dialog, and Sidebar components is already 80% of the production implementation
• Dark mode, responsive behavior, keyboard nav, and focus management come free from the Radix primitives underneath

The 128 patterns in the docs site are designed as starting points. Copy a shell layout, drop in some element variants, wire up data — you have a working internal tool or customer-facing prototype in an afternoon, and it doesn't need to be thrown away afterward.

Quick start

import "@lantern-product/ui/styles";
import { Button, Card, CardContent, Badge } from "@lantern-product/ui";

Browse components, elements, and shells at design.lantern.codes. Every demo now includes a code toggle so you can copy the JSX directly.

What's next

This is a beta. We're collecting feedback on token values, component APIs, and missing patterns. File issues in the repo or drop notes in the design-system channel.