Chip

<Chip> is the design guide's chip idiom, packaged as a component — the same badge you see as the topbar's DEV indicator, the version chips, and inline status chips. It is available in every MDX page without an import (part of the MDX component map), and exported from the library root for use in custom components.

Implementing badges

Every chip in the shell shares one typographic core. If you are building a badge — in a custom component, a consuming site, or another DreamLake surface — this is the spec, and <Chip> renders it exactly:

The three variants pick the text / fill pair from the theme tokens, so they work in both modes:

Props

Custom colors

For a color outside the three variants, override via style — the border is currentColor-derived, so it follows automatically:

<Chip style={{ color: 'oklch(62% .15 145)',
               background: 'color-mix(in srgb, oklch(62% .15 145) 12%, transparent)' }}>
  passing
</Chip>

This is exactly how the shell's own TestStatus badge gets its data-driven pass/fail/skip colors — it renders through <Chip> with style overrides.

Injecting badges

Three injection points, in order of how structural they are:

1. Topbar version chips (config)

The chips after the brand cluster come from the versionChips config field — one { label, version, dropdown? } entry per chip; dropdown: true makes it the version switcher:

initDocs({
  site: {
    versionChips: [{ label: 'dockit', version: __DOCKIT_VERSION__, dropdown: true }],
  },
  // …
})

See Topbar for where they render and Releases & versioning for the manifest behind the dropdown.

2. Standalone VersionBadge (component)

VersionBadge — the two-segment [ label | v0.2.5 ] chip — is exported from the library root, so the version switcher can live outside the topbar (a custom footer, a landing hero):

import { VersionBadge } from '@dreamlake/dockit'

<VersionBadge label="dockit" version="0.2.5" dropdown />

Its segments follow the chip spec above; only the two-segment layout is bespoke.

3. Inline in MDX (content)

<Chip> is registered in the MDX component map, so any page on any dockit site can drop a badge into prose with no import:

The legacy importer is <Chip variant="warn">deprecated</Chip> as of 0.3.

The legacy importer is deprecated as of 0.3.

For badges whose content is data, the worked example is <TestStatus> — the inline test-status chip from the lakeshore docs. An MDX page injects it with just an id, and the chip fetches its state from a CI-generated /test-results.json:

The install path is covered by <TestStatus suite="unit" /> in CI.

It degrades gracefully — a muted unknown chip when the id (or the manifest) doesn't exist, as on this site. See StatusTable for the full data pipeline.

Site-specific badge components follow the same route: build them on <Chip> and register them via the mdxComponents config field so your pages can use them without imports.

Badges the shell already owns

Don't recreate these — they render automatically:

• DEV badge — the warn DEV chip in the topbar actions cluster while hidden pages are revealed (Cmd+Shift+D); clicking it turns the toggle off. See Topbar.
• Git-hash chip — set gitHash in the site config and a mono commit-hash chip renders after the version chips.
• Sidebar draft chip — the "awaiting review" marker from the draft frontmatter flag.