Frontmatter
Frontmatter
Frontmatter — это блок метаданных (данных о данных) в самом начале текстового
файла, отделённый от основного содержимого специальными разделителями, чаще
всего тремя дефисами---. Внутри блока — обычно YAML: заголовок, дата, теги
и любые другие поля, которые описывают документ, но не являются его текстом.
История
Термин пришёл не из программирования, а из книгоиздания. В типографике
«front matter» — это всё, что идёт в книге до основного текста: титульный
лист, выходные данные, оглавление, посвящение, предисловие. Страницы front
matter традиционно даже нумеруются отдельно — римскими цифрами, чтобы
подчеркнуть: это ещё не книга, это сведения О книге.
В мир разработки термин притащил Том Престон-Вернер (Tom Preston-Werner),
один из сооснователей GitHub. В 2008 году он написал Jekyll — генератор
статических сайтов (программа, которая превращает папку с текстовыми файлами
в готовый HTML-сайт). Джекиллу нужно было где-то хранить заголовок поста,
дату публикации, шаблон оформления. Престон-Вернер решил не заводить
отдельную базу данных и не придумывать свой формат, а положить метаданные
прямо в начало Markdown-файла, обернув их в YAML и отбив тремя дефисами.
Так родился «YAML front matter» — и название, и синтаксис.
Контекст эпохи важен. В 2008 году блоги жили в основном на WordPress и
подобных CMS (системах управления контентом) с базой данных MySQL. Это
означало хостинг с PHP, обновления безопасности, взломы, бэкапы. Идея
Jekyll была радикально проще: пост — это просто файл в git-репозитории,
метаданные — прямо в файле, сайт — статические HTML-страницы, которые
нечего взламывать. GitHub Pages, запущенный в том же 2008-м, сделал Jekyll
своим движком по умолчанию — и frontmatter мгновенно стал стандартом
де-факто для всей экосистемы статических сайтов.
Ключевые вехи дальше:
- 2013 — Стив Франсиа (Steve Francia) выпускает Hugo на Go. Hugo
расширяет идею: кроме YAML (---) поддерживает TOML (разделитель+++)
и JSON (просто фигурные скобки в начале файла). - 2015 — Gatsby (Кайл Мэтьюс) приносит frontmatter в мир React:
метаданные из Markdown-файлов становятся доступны через GraphQL. - 2017 — Docusaurus от Facebook (теперь Meta) делает frontmatter
стандартом для технической документации. - Примерно 2020-е — GitHub начинает рендерить YAML frontmatter в
Markdown-файлах красивой таблицей прямо в интерфейсе; Obsidian строит
на frontmatter свою систему свойств заметок (Properties), а инструменты
вроде Claude Code — конфигурацию агентов, навыков и памяти.
Владельца у frontmatter нет — это не стандарт с RFC, а соглашение
(convention), которое каждый инструмент реализует чуть по-своему. В этом
и сила его, и главная боль, о которой ниже.
Что это такое
Идея frontmatter — разделить в одном файле два слоя: что документ
содержит и что документ собой представляет. Тело — для человека,
который будет читать. Шапка — для машины, которая будет обрабатывать.
Выглядит это так:
---
title: Как я перестал бояться и полюбил rsync
date: 2026-07-07
tags: [инструменты, devops]
draft: false
---
Здесь начинается обычный текст статьи...
Парсер (программа-разборщик) видит --- в первой строке, читает всё до
следующего ---, скармливает это YAML-библиотеке и получает словарь:
{title: "...", date: ..., tags: [...], draft: false}. Всё, что после
второго разделителя, — тело документа, оно уходит в Markdown-рендерер.
Полезно понимать, чем frontmatter отличается от соседних решений:
- Frontmatter vs HTML
<head>. Похожая идея — метаданные отдельно от
содержимого, — но<head>живёт в конечном формате (HTML), а frontmatter
в исходном (Markdown). Обычно генератор сайта как раз превращает поля
frontmatter в теги<head>:title→<title>,teaser→
<meta name="description">. - Frontmatter vs sidecar-файл (файл-спутник, лежащий рядом:
post.md+
post.meta.json). Sidecar не ломает исходный формат, но метаданные легко
потерять при копировании — файлы разъезжаются. Frontmatter намертво
привязан к содержимому: один файл — одна сущность. - Frontmatter vs база данных. База даёт валидацию, связи, транзакции
и поиск, но требует инфраструктуры. Frontmatter — это «база данных для
бедных»: каждый файл — строка таблицы, поля frontmatter — колонки, а
запросы делает генератор при сборке.
Важная тонкость: строго говоря, файл с frontmatter — невалидный
Markdown. Спецификация Markdown ничего не знает о --- в начале файла
(три дефиса в ней — это горизонтальная линия или подчёркивание заголовка).
Всё держится на договорённости: инструменты, которые «в теме», сначала
отрезают шапку, а уже остаток парсят как Markdown. Инструмент «не в теме»
покажет твои метаданные как обычный текст — отсюда странные таблицы или
линии в начале документа, если открыть файл не тем рендерером.
Аналогии из жизни
Титульный лист книги. Открываешь книгу — и до первой главы идут
страницы с названием, автором, годом, издательством. Это метаданные:
они описывают книгу, но не являются её сюжетом. Frontmatter — ровно это.
Где ломается: титульный лист читатель видит, а frontmatter из
отрендеренной статьи обычно вырезается — читатель блога никогда не видит
сырых полей slug или draft. Метаданные книги — часть продукта,
метаданные файла — часть производства.
Транспортная накладная на коробке. Курьер не вскрывает коробку, чтобы
узнать, куда её везти, — всё написано снаружи: адрес, вес, хрупкость.
Сортировочный центр обрабатывает тысячи коробок, читая только наклейки.
Так и генератор сайта: чтобы построить список статей с датами и тегами,
ему не нужно «понимать» тексты — достаточно прочитать шапки. Где
ломается: накладная существует отдельно от содержимого — её можно
переклеить, потерять, коробку можно переупаковать. Frontmatter же внутри
самого файла: потерять его отдельно от текста невозможно, но и «переклеить»
без вскрытия файла — тоже.
Анкета в регистратуре поликлиники. Прежде чем попасть к врачу, ты
заполняешь бланк: имя, год рождения, аллергии, жалобы. Врач за 10 секунд
сканирует анкету и понимает контекст, не расспрашивая тебя с нуля. Поля
стандартные, поэтому любая медсестра найдёт нужное мгновенно. Где
ломается: анкету заполняет и читает человек, и человек же переспросит,
если поле заполнено криво. YAML-парсер не переспросит — он либо молча
поймёт тебя неправильно, либо упадёт с ошибкой на весь файл. Машина
строже регистратуры.
Как это работает
Разберём по шагам, что происходит, когда генератор сайта встречает файл
с frontmatter. Псевдокод любого парсера выглядит примерно так:
прочитать файл
если первая строка == "---":
искать следующую строку "---"
всё между ними → yaml.parse() → словарь метаданных
всё после → тело документа
иначе:
метаданные = пустой словарь
тело = весь файл
Дальше по конвейеру:
-
Обнаружение. Парсер смотрит на самое начало файла. Разделитель
должен быть в первой строке — даже пустая строка или невидимый
BOM (byte order mark, служебные байты кодировки в начале файла) перед
---ломают распознавание: парсер решает, что frontmatter нет вообще. -
Извлечение. Всё между разделителями вырезается и передаётся
YAML-парсеру. Здесь живут главные грабли, потому что YAML — формат
с сюрпризами:
- Двоеточие в значении.title: Frontmatter: зачем он нужен—
ошибка парсинга: YAML видит второе двоеточие и не понимает структуру.
Лечится кавычками:title: "Frontmatter: зачем он нужен".
- Табы. YAML запрещает табуляцию в отступах — только пробелы.
- Автомагия типов.version: 1.10превратится в число1.1,
answer: no— в булевоfalse, а дата может стать объектом даты
со сдвигом часового пояса. Классика: норвежский код страныNO
в старых YAML-парсерах превращался вfalse.
- Регистр и синонимы.Tagsиtags— разные ключи; парсер не
будет догадываться. -
Валидация и дефолты. Хороший генератор проверяет обязательные поля
(нетtitle— падаем с понятной ошибкой или подставляем имя файла)
и наполняет необязательные значениями по умолчанию (draft: false,
layout: post). -
Слияние с контекстом. Метаданные файла объединяются с настройками
уровня папки и сайта. В Jekyll это называется «каскад»: значения из
_config.ymlперекрываются значениями папки, а те — значениями файла.
Знакомый принцип, правда? Так же работает CSS. -
Использование. Поля разлетаются по местам:
title— в<title>и
<h1>,date— в сортировку ленты,tags— в страницы тегов,slug—
в URL,draft: true— сигнал «не публиковать». Тело файла тем временем
отдельно проходит через Markdown-рендерер.
Обрати внимание на асимметрию последствий. Ошибка в теле — это криво
отрендеренный абзац, косметика. Ошибка во frontmatter — это упавшая
сборка всего сайта или молча пропавшая из ленты статья. Метаданные —
машиночитаемый контракт, и машина спрашивает с них строже.
Самые частые поломки frontmatter
Двоеточие или # в значении без кавычек, табуляция вместо пробелов,
пустая строка перед первым ---, кривая кодировка с BOM. Если сборка
упала на «неправильном YAML» — начинай проверку с этих четырёх пунктов,
в 90% случаев дело в одном из них.
Где встречается в обычной жизни
- Заметки в Obsidian. Когда добавляешь заметке «свойства» (Properties)
через красивый интерфейс — дату, статус, ссылки, — Obsidian на самом деле
пишет YAML frontmatter в начало твоего.md-файла. Открой заметку в
обычном блокноте — увидишь---и поля. - README и файлы на GitHub. Если в Markdown-файле репозитория есть
YAML-шапка, GitHub отрендерит её аккуратной таблицей над текстом. Многие
видели эту таблицу, не зная, откуда она берётся. - Любой блог на «современном» стеке. Читаешь статью на личном сайте
разработчика — с вероятностью выше половины это Hugo, Jekyll, Astro или
Next.js, и у исходника этой статьи есть frontmatter с заголовком и датой. - Шаблоны тикетов и issue. В GitHub шаблоны для issue и pull request —
это Markdown-файлы с frontmatter (name,about,labels), который
говорит GitHub, как показать шаблон в меню. - Экспорт из заметочников. Выгружаешь заметки из Notion, Bear или
Craft в Markdown — большинство инструментов кладёт метаданные (дату
создания, теги) именно в frontmatter, потому что больше некуда.
Где встречается в IT и бизнесе
- Генераторы статических сайтов — родная стихия: Jekyll, Hugo, Astro,
Eleventy, Gatsby, Next.js/Nuxt в режиме контент-сайтов. Нужно, когда
контента много, он версионируется в git, а база данных — лишняя сущность. - Техническая документация. Docusaurus, MkDocs Material, GitBook,
Mintlify: frontmatter задаёт порядок страниц в сайдбаре, хлебные крошки,
видимость. Нужно, когда документацию пишут инженеры в том же репозитории,
что и код. - Git-based CMS. Decap CMS (бывший Netlify CMS), Tina, Sveltia дают
редактору веб-форму, а «под капотом» просто пишут frontmatter + Markdown
в git. Нужно, когда контент-менеджер не должен видеть git, но контент
должен жить в git. - Конфигурация AI-агентов. Claude Code хранит навыки (skills),
памятки и определения субагентов как Markdown с frontmatter: в шапке —
имя, описание, метаданные для машинного выбора, в теле — инструкции.
Тот же паттерн: машина читает шапку, чтобы решить, читать ли ей тело. - Пайплайны обработки документов. Pandoc — конвертер «из всего во
всё» — понимает YAML-блок метаданных и превращает его в свойства
документа Word, поля PDF или теги EPUB. Нужно, когда из одного исходника
собираются разные форматы.
Общий класс задач: много однотипных текстовых единиц + необходимость
их машинной сортировки/фильтрации + желание обойтись без базы данных.
Если все три пункта совпали — ты в территории frontmatter.
Кто пользуется
- GitHub Pages — миллионы сайтов на Jekyll, где frontmatter обязателен
для каждого поста. Сам сайт документации GitHub (docs.github.com) — тоже
Markdown с frontmatter, репозиторий открыт. - Meta — Docusaurus питает документацию React, Jest, Babel и сотен
других open-source проектов. - Obsidian — по разным оценкам, больше миллиона активных пользователей;
с версии, где появились Properties (примерно 2023 год), frontmatter стал
центральным механизмом организации заметок. - Vercel/Netlify-экосистема — блоги и лендинги на Next.js и Astro
почти поголовно держат контент в MDX/Markdown с frontmatter. - Anthropic — Claude Code использует frontmatter для skills, агентов
и памяти; этот самый блог генерируется агентом, который пишет статьи
ровно в этом формате.
Точных цифр «сколько файлов с frontmatter в мире» не существует — это
соглашение, а не сервис с телеметрией. Но косвенная оценка: только на
GitHub счёт Markdown-файлов с YAML-шапкой идёт на десятки миллионов.
Альтернативы и конкуренты
- Sidecar-файлы (
post.md+post.json).
Плюс: исходный файл остаётся стопроцентно валидным для любого парсера.
Минус: файлы разъезжаются при копировании/переименовании, целостность
держится на дисциплине. - База данных / headless CMS (Contentful, Strapi, Sanity).
Плюс: валидация схемы, связи между сущностями, права доступа, API.
Минус: инфраструктура, деньги, vendor lock-in (привязка к поставщику),
контент живёт вне git. - MDX с экспортами (метаданные как JavaScript-код:
export const meta = {...}прямо в документе).
Плюс: настоящие типы, можно вычислять значения, проверяется линтером.
Минус: документ перестаёт быть просто текстом — без JS-тулчейна он
нечитаем; писать может только разработчик. - TOML/JSON frontmatter (тот же блок, другой синтаксис; поддерживает
в основном Hugo).
Плюс: TOML избавлен от YAML-сюрпризов с типами, JSON строг и однозначен.
Минус: поддержка сильно уже — за пределами Hugo почти никто не понимает;
JSON многословен и не даёт комментариев.
Когда НЕ стоит использовать
- Метаданные реляционные и их много. Если у статьи есть автор со своей
карточкой, автор состоит в отделах, статьи связаны между собой — это
графы и связи, и вытаскивать их из тысяч файловых шапок при каждой сборке
всё медленнее и хрупче. Потому что frontmatter — плоский словарь на файл,
а не база с внешними ключами. - Файл обязан оставаться валидным для строгого потребителя. Если твой
Markdown уходит в систему, которая не знает о frontmatter (старый
рендерер, чужой API, строгий линтер), шапка вылезет мусором в начале
документа. Потому что frontmatter — соглашение, а не часть стандарта
Markdown. - Метаданные меняются чаще и отдельно от контента. Счётчик просмотров,
статус модерации, лайки — если такие поля писать во frontmatter, каждое
изменение — это правка файла, коммит и пересборка. Потому что frontmatter
версионируется вместе с текстом, а оперативные данные должны жить там,
где запись дешёвая, — в базе.
Лакмусовая бумажка
Спроси: «кто и когда меняет это поле?» Если человек и в момент редактирования текста — поле просится во frontmatter. Если машина и в любой момент времени — полю место в базе данных. Смешивать эти два мира в одной шапке — самый частый архитектурный промах с frontmatter.
Связанные понятия
- YAML — формат сериализации данных «для людей», основной синтаксис
frontmatter; отдельная большая тема со своими граблями. - Markdown — язык разметки текста, в файлах которого frontmatter
чаще всего и живёт. - Статический генератор сайтов (SSG) — программа, собирающая сайт из
файлов с frontmatter в готовый HTML (Jekyll, Hugo, Astro). - Метаданные — «данные о данных»; frontmatter — лишь один из способов
их хранить, наряду с EXIF в фото и ID3-тегами в MP3. - Sidecar-файл — файл-спутник с метаданными, лежащий рядом с основным;
главный конкурент frontmatter в мире фото и видео. - JAMstack — архитектурный подход (JavaScript + API + Markup), в
котором контент со frontmatter — стандартный источник данных.
Литература и источники
- Документация Jekyll, раздел «Front Matter» — первоисточник соглашения:
https://jekyllrb.com/docs/front-matter/ (en) - Документация Hugo, «Front matter» — самый полный обзор форматов
(YAML/TOML/JSON) и каскада значений: https://gohugo.io/content-management/front-matter/ (en) - Спецификация YAML 1.2.2 — чтобы понимать, что именно парсится в шапке:
https://yaml.org/spec/1.2.2/ (en) - Wikipedia (en): статья «Book design» — про исходный, книгоиздательский
смысл термина front matter. - Документация Pandoc, раздел про YAML metadata blocks — как метаданные
переезжают между форматами: https://pandoc.org/MANUAL.html (en) - Про грабли YAML — искать в Google «yaml norway problem» (en): разбор
классических сюрпризов типизации, которые бьют и по frontmatter.
Где встретилось у меня
Вчера в пайплайне daily-digest сборка HTML споткнулась о битый
YAML-frontmatter одной из старых статей — двоеточие в строковом значении
без кавычек, ровно та грабля из раздела «Как это работает». Плюс сам
генератор статей, выбирая тему дня, отметил frontmatter как один из самых
частых терминов в логах: весь этот блог — Markdown-файлы с YAML-шапками,
из которых build.sh собирает HTML.
Краткое резюме
- Frontmatter — блок метаданных в начале текстового файла между
---,
обычно YAML: машина читает шапку, человек — тело. - Придумал Том Престон-Вернер для Jekyll в 2008-м; название взято из
книгоиздания, где front matter — титульные страницы до основного текста. - Это соглашение, а не стандарт: строго говоря, файл с шапкой — невалидный
Markdown, и инструмент «не в теме» покажет её как текст. - Сила — в простоте: контент и метаданные в одном файле, версионируются
вместе в git, база данных не нужна. - Главные грабли — YAML: двоеточия без кавычек, табы, автомагия типов;
ошибка в шапке ломает сборку, а не абзац. - Не годится для реляционных и часто меняющихся данных — там нужна база,
а не шапка файла.