Staaarter

Database Migration Timeline

A timeline-style migration tracker section: a vertical connecting line runs alongside a list of schema migrations, each marked with a status dot (applied, pending, or failed), its migration filename in monospace, a one-line description of what it changes, and a timestamp. Built for changelog pages and internal ops dashboards.

By Staaarter Team
DevTools
Docs
Live preview

Docs

Installation

A real shadcn registry command, not a copy-paste stand-in: it fetches this block plus its dependencies and any missing npm packages, and installs them straight into your project.

npx shadcn add https://staaarter.com/r/database-migration-timeline.json

Prefer not to use the CLI? Copy the source from the Code toggle above into src/components/blocks/devtools/devtools13.tsx instead.

Usage

The file also exports devtools13Demo, the exact props behind the preview above. Spread it to get a working section in one line, then replace it with your own data.

import { Devtools13, devtools13Demo } from "@/components/blocks/devtools/devtools13";

export default function Page() {
  return <Devtools13 {...devtools13Demo} />;
}

Props

PropTypeDefaultDescription
headingstring"Database migration timeline"Section heading.
descriptionstringundefinedSection intro text below the heading.
migrationsMigration[][]Timeline entries, expected in run order (oldest first, matching the demo data).
classNamestringnoneExtra classes for the outer section element.

Types

type MigrationStatus = "applied" | "pending" | "failed";

type Migration = {
  name: string;
  description: string;
  timestamp: string;
  status: MigrationStatus;
};

Behavior notes

  • Entirely static; no client-side interactivity. The connecting line is a single border-left on the wrapping container, not per-item SVG, so it runs continuously behind every dot regardless of list length.
  • Status dot color and icon are fixed by status value (applied=emerald check, pending=amber clock, failed=red X) and are not configurable beyond changing status.
  • timestamp is a plain display string; the demo data mixes past timestamps for applied/failed entries with "Scheduled for..." and "Not yet run" text for pending ones, but the component itself does not interpret or format the string.
  • Order is entirely the caller's responsibility: the component renders migrations in array order and does not sort by timestamp or status.