Zum Inhalt springen
duxt

Granularität

Eine Seite pro Release, oder die Datei als die eine Seite, als die sie geschrieben wurde.

granularity ist die eine Option, die der Typ liest. Sie nimmt split — den Standard — oder flat, und der Unterschied reicht weiter als die Seitenzahl.

{
  type: 'changelog',
  path: 'CHANGELOG.md',
  label: 'Changelog',
  options: { granularity: 'flat' }
}

split — eine Seite pro Release

Der Standard, und wofür eine Release-Historie da ist. Jedes Release wird zu einer eigenen Seite unter einer generierten Übersicht, was vier Dinge kauft, die eine einzelne Seite nicht haben kann:

  • einen Deep Link auf ein Release, und auf eine Gruppe darin;
  • einen Suchtreffer, der das Release ist und nicht die ganze Datei;
  • einen Feed-Eintrag pro Release, sobald feed.path die Sektion benennt;
  • einen llms.txt-Eintrag pro Release, sodass ein Modell, das fragt, was sich in 2.1.0 geändert hat, dieses Release bekommt und nicht vierhundert Kilobyte Historie.

Die Übersicht ist eine Zeitleiste — jedes Release, neueste zuerst, mit seinem Datum und den Arten von Änderung daneben, filterbar nach diesen Arten. Die Einträge selbst bleiben auf den Release-Seiten: Sie auf der Übersicht zu wiederholen würde das ganze Changelog doppelt in den Suchindex, in llms-full.txt und in den Feed legen.

Getrennte Seiten rendern in einem eigenen Layout: die Releases in der Seitenleiste, eine auf ein Maß begrenzte Lesespalte und eine Inhaltsspalte, die die Gruppen listet. Siehe Komponenten.

flat — die Datei, wie sie ist

Eine Seite, die die Datei hält, wie sie geschrieben wurde. Für ein Projekt, das sein Changelog einfach gezeigt haben will.

Ein flaches Changelog ist eine gewöhnliche Doku-Seite und behält das Doku-Gerüst — die Prosa-Seitenleiste, den Brotkrumenpfad und ein Inhaltsverzeichnis, das die Releases listet, was eine lange Datei genau will. Deshalb wird die Layout-Frage aus den Optionen der Deklaration beantwortet und nicht vom Typ festgelegt: Derselbe Typ erzeugt zwei verschiedene Dinge.

Nichts wird umgeschrieben außer dem Titel. Das eigene # Changelog der Datei geht, weil die Seite ihre Überschrift aus title zieht und ein zweites <h1> im Körper sowohl ein Duplikat als auch ein Barrierefreiheits-Befund ist. Jede Release-Überschrift bleibt genau dort, wo das Release-Werkzeug sie hingeschrieben hat — was „unverändert“ heißen muss, sonst ist der Modus nicht die Notluke, für die es ihn gibt.

Wozu greifen

Du willstNimm
Eine Release-Historie, durch die Leser navigieren und verlinkensplit
Einen Feed, oder Einträge pro Release in llms.txtsplit
Die Datei gezeigt wie geschrieben, ohne erfundene URLsflat
War diese Seite hilfreich?