Frontmatter

Jedes Frontmatter-Feld, das eine Seite akzeptiert, alle optional — Titel, Beschreibung, Sidebar, SEO, Suche und alles Weitere, mit der jeweiligen Funktion.

Jede Seite akzeptiert das folgende Frontmatter. Alle Felder sind optional.

Sidebar

sidebar:
  label: Install
  order: 2
  icon: download
  badge: New
  hidden: false

SEO

seo:
  title: Install Blume
  description: Install Blume and scaffold your first project.
  image: /og/install.png
  canonical: https://acme.com/install
  noindex: false

Suche

search:
  exclude: false
  tags: [api]

Changelog

Changelog-Einträge (type: changelog) akzeptieren ein optionales changelog-Objekt für umfangreichere Feed- und Anzeige-Metadaten:

type: changelog
changelog:
  version: 1.2.0
  date: 2026-06-20
  category: Features

date kann hier oder auf der obersten Ebene stehen — beide speisen den Changelog-RSS-Feed. Siehe Changelog für die generierte Timeline-Seite und den Feed.

Eigene Schlüssel

Jeder Schlüssel außerhalb dieser Referenz lässt den Build fehlschlagen, sodass Tippfehler früh auffallen. Projekte mit eigenen Metadaten können zusätzliche Schlüssel über frontmatter.extend in blume.config.ts zulassen, jeweils validiert durch ein Schema, das das Projekt bereitstellt:

import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  frontmatter: {
    extend: {
      owner: z.string(),
      reviewedAt: z.coerce.date().optional(),
    },
  },
});

---
title: Install
owner: "@sam"
reviewedAt: 2026-06-20
---

Schemas werden über die Standard-Schema-Schnittstelle akzeptiert, sodass Zod (in der Version, die Ihr Projekt installiert), Valibot und ArkType allesamt funktionieren. Jeder deklarierte Schlüssel wird auf jeder Seite validiert — auch fehlende —, sodass ein erforderliches Schema den Schlüssel site-weit erzwingt; markieren Sie ihn mit .optional(), um nur dort zu validieren, wo er vorhanden ist. Alle übrigen Schlüssel bleiben streng validiert, und eingebaute Felder können nicht neu deklariert werden.

Schlüssel pro Typ

Um Schlüssel nur für einen Inhaltstyp zu verlangen — den status eines RFC, die severity eines Incident-Reports — deklariere sie stattdessen unter content.types, geschlüsselt nach dem Frontmatter-type, für den sie gelten:

import { defineConfig } from "blume";
import { z } from "zod";

export default defineConfig({
  content: {
    types: {
      rfc: {
        frontmatter: {
          domain: z.string(),
          status: z.enum(["draft", "review", "enforced"]),
        },
      },
    },
  },
});

---
title: OpenAPI request schemas
type: rfc
domain: architecture
status: enforced
---

Schlüssel pro Typ folgen denselben Validierungsregeln wie extend, beschränkt auf Seiten, deren aufgelöster type passt — einschließlich Seiten ohne type, wenn die Deklaration für content.defaultType gilt. Ein Schlüssel gehört zu einer Deklaration, site-weit oder pro Typ, nicht zu beiden. Und ein Schlüssel, der nur für einen anderen Typ deklariert ist, bleibt anderswo unbekannt, sodass ein versehentliches status auf einer gewöhnlichen Doc-Seite den Build weiterhin fehlschlagen lässt.

Eine Seite, die die Validierung nicht besteht, lässt blume build mit einer Diagnose fehlschlagen, die Datei und Schlüssel benennt. Mit --no-strict läuft der Build dennoch erfolgreich durch und die fehlerhaften Seiten werden aus der Ausgabe entfernt — die Build-Zusammenfassung meldet, wie viele.

Schemas werden aus blume/schema für Editor- und Migrations-Tooling exportiert.