फ्रंटमैटर

हर वह फ्रंटमैटर फ़ील्ड जो कोई पृष्ठ स्वीकार करता है, सभी वैकल्पिक — title, description, sidebar, SEO, search, और बाक़ी सब, साथ में यह कि हर एक क्या नियंत्रित करता है।

हर पृष्ठ निम्नलिखित फ्रंटमैटर स्वीकार करता है। सभी फ़ील्ड वैकल्पिक हैं।

साइडबार

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

खोज

search:
  exclude: false
  tags: [api]

चेंजलॉग

चेंजलॉग प्रविष्टियाँ (type: changelog) समृद्ध फ़ीड और डिस्प्ले मेटाडेटा के लिए एक वैकल्पिक changelog ऑब्जेक्ट स्वीकार करती हैं:

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

date यहाँ रह सकती है या शीर्ष स्तर पर — दोनों ही चेंजलॉग RSS फ़ीड को संचालित करती हैं। जनरेट किए गए टाइमलाइन पृष्ठ और फ़ीड के लिए चेंजलॉग देखें।

कस्टम कुंजियाँ

इस संदर्भ से बाहर की कोई भी कुंजी बिल्ड को विफल कर देती है, जिससे टाइपो जल्दी पकड़ में आ जाते हैं। जो प्रोजेक्ट अपना स्वयं का मेटाडेटा रखते हैं, वे blume.config.ts में frontmatter.extend के माध्यम से अतिरिक्त कुंजियाँ शामिल कर सकते हैं, जिनमें से प्रत्येक को प्रोजेक्ट द्वारा उपलब्ध कराए गए स्कीमा से मान्य किया जाता है:

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
---

स्कीमा Standard Schema इंटरफ़ेस के ज़रिए स्वीकार किए जाते हैं, इसलिए Zod (आपका प्रोजेक्ट जो भी संस्करण इंस्टॉल करता है), Valibot, और ArkType सभी काम करते हैं। घोषित की गई हर कुंजी हर पृष्ठ पर मान्य की जाती है — अनुपस्थित कुंजियाँ भी शामिल — इसलिए एक आवश्यक स्कीमा उस कुंजी को पूरी साइट पर लागू करता है; इसे केवल वहीं मान्य करने के लिए जहाँ यह मौजूद है, इसे .optional() चिह्नित करें। अन्य सभी कुंजियाँ सख़्ती से मान्य की जाती रहती हैं, और अंतर्निहित फ़ील्ड्स को पुनः घोषित नहीं किया जा सकता।

प्रति-प्रकार कुंजियाँ

कुंजियों को केवल एक सामग्री प्रकार पर आवश्यक बनाने के लिए — किसी RFC का status, किसी घटना रिपोर्ट का severity — उन्हें इसके बजाय content.types के अंतर्गत घोषित करें, जो उस फ्रंटमैटर type से कुंजीबद्ध हों जिस पर वे लागू होती हैं:

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
---

प्रति-प्रकार कुंजियाँ extend के समान ही मान्यता नियमों का पालन करती हैं, जो उन पृष्ठों तक सीमित होती हैं जिनका हल किया गया type मेल खाता है — उन पृष्ठों सहित जो कोई type निर्धारित नहीं करते, जब घोषणा content.defaultType के लिए हो। एक कुंजी किसी एक ही घोषणा से संबंधित होती है, साइट-व्यापी या प्रति-प्रकार, दोनों से नहीं। और जो कुंजी केवल किसी अन्य प्रकार के लिए घोषित की गई हो, वह अन्यत्र अज्ञात ही रहती है, इसलिए किसी सामान्य doc पृष्ठ पर भटका हुआ status अब भी बिल्ड को विफल कर देता है।

जो पृष्ठ मान्यता में विफल होता है, वह blume build को एक ऐसे डायग्नोस्टिक के साथ विफल कर देता है जो फ़ाइल और कुंजी का नाम बताता है। --no-strict के साथ, बिल्ड फिर भी सफल होता है और विफल पृष्ठ आउटपुट से हटा दिए जाते हैं — बिल्ड सारांश बताता है कि कितने।

एडिटर और माइग्रेशन टूलिंग के लिए स्कीमा blume/schema से एक्सपोर्ट किए जाते हैं।