Open-Source-Projekt
bruits/satteri avatar
bruits/satteri

Sätteri im Detail: Markdown- und MDX-Kompilierung in Rust mit JavaScript-Plugins

Leistungsstarke Markdown- und MDX-Verarbeitung für das JavaScript-Ökosystem.

1.257 Sterne34 ForksRustMIT

Auf einen Blick

Was ist das?
Eine Rust-Pipeline für Markdown und MDX aus dem Kollektiv Bruits, die Plugins in JavaScript ausführt. Was die Crates leisten, wo die Grenzen liegen und für wen das Projekt passt.
Für wen ist es gedacht?
Sätteri passt für Teams, die in Vite arbeiten und große Mengen an .md- und .mdx-Inhalten verarbeiten, ohne das unified-Plugin-Modell aufzugeben. Weniger geeignet ist es für Projekte, die die vollständige remark/rehype-Plugin-Vielfalt brauchen oder auf stabile 1.0-Versionen angewiesen sind, denn die Pakete stehen noch am Anfang.
Darf ich es kommerziell nutzen?
Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
Wird es noch gepflegt?
Ja. Die letzten Commits kamen vor 2 Tagen.
In welcher Sprache ist es geschrieben?
Hauptsächlich Rust, laut der Sprachstatistik von GitHub.

Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.

TIEFGEHENDE OPEN-SOURCE-ANALYSE

Warum Sätteri Markdown in Rust kompiliert

Sätteri greift ein Problem auf, das viele Content-Seiten im JavaScript-Umfeld kennen: Markdown und MDX lassen sich mit remark und rehype verarbeiten, doch bei großen Inhaltsmengen wird das Parsen zum Flaschenhals. Das Projekt aus dem Rust-Kollektiv Bruits verlagert genau diesen Teil nach Rust. Laut README parst und kompiliert die Pipeline in Rust, während Plugins in JavaScript laufen.

Der Vorteil dieses Schnitts liegt darin, dass bestehende Plugin-Kenntnisse weiter nutzbar bleiben, während die rechenintensive Arbeit kompiliertem Code überlassen wird. Das Monorepo enthält sieben Rust-Crates und drei npm-Pakete, alle unter der MIT-Lizenz. Die Dokumentation liegt unter satteri.bruits.org, dazu gibt es einen Playground zum direkten Ausprobieren im Browser.

Wer heute Vite einsetzt und .md- oder .mdx-Dateien importiert, findet mit vite-plugin-satteri einen konkreten Einstiegspunkt, ohne die Pipeline von Hand aufsetzen zu müssen.

Die Pipeline von parse über convert zu compile

Der Datenfluss folgt drei Stufen: parse, convert und compile. Das Crate satteri bündelt diese High-Level-API und ist damit der Hauptzugang für Rust-Nutzer. In der Mitte steht satteri-ast mit MDAST- und HAST-Knotentypen, Codecs, Baumeoperationen und der Konvertierung zwischen beiden Formaten. MDAST bezeichnet den Markdown-Baum, HAST den HTML-Baum, ein Muster, das Sätteri vom unified-Ökosystem übernimmt.

Darunter arbeitet satteri-arena als Arena-Allokator mit binären Buffer-Primitiven, also die Schicht, die schnelle Speicherverwaltung für Parser und Compiler bereitstellt. Die Brücke nach außen bildet satteri-napi-binding: Es exponiert die Rust-Pipeline über NAPI an JavaScript, so dass npm-Pakete wie vite-plugin-satteri die Crates aufrufen können, ohne dass Anwender selbst Rust bauen müssen.

Das README beschreibt die Stufen nur auf Ebene der Crate-Beschreibungen. Wie Plugins genau in die einzelnen Stufen eingreifen, steht dort nicht; dafür verweist das Projekt auf die API-Referenz in der Dokumentation.

satteri-mdxjs-rs und satteri-pulldown-cmark: zwei Forks mit Aufgabe

Zwei Crates sind Forks bestehender Projekte, und ihre Existenz erklärt viel über die Architektur. satteri-pulldown-cmark basiert auf pulldown-cmark, einem Pull-Parser für CommonMark, und erweitert ihn um Support für MDX-Erweiterungen. Ohne diesen Fork würde der Parser EJS-artige JSX-Blöcke in Markdown-Quellen nicht verstehen.

Das zweite Fork ist satteri-mdxjs-rs, ein MDX-zu-JavaScript-Compiler, der auf mdxjs-rs von Titus Wormer zurückgeht und für OXC angepasst wurde. OXC ist ein Rust-Parser und Compiler für JavaScript, der das Kompilierergebnis schneller verarbeiten kann als die Original-Version. Für das Parsing von JSX in MDX-Dateien nutzt Sätteri damit ebenfalls Rust statt eines JavaScript-Werkzeugs.

Das README nennt außerdem Lightning CSS als Vorbild für die optimierte JavaScript-Visitor-API, die den Übergang zwischen Rust und JavaScript leisten soll. Die Interop-Erfahrung dieser Projekte floss laut Danksagung direkt in den Entwurf von Sätteri ein.

vite-plugin-satteri: .md und .mdx in Vite importieren

Für die Praxis im JavaScript-Ökosystem ist das npm-Paket vite-plugin-satteri der interessanteste Teil. Es erlaubt, .md- und .mdx-Dateien direkt in Vite-Projekten zu importieren, und rendert Codeblöcke optional über das begleitende Paket satteri-expressive-code, das als HAST-Plugin Expressive Code zur Darstellung nutzt.

Die Release-Historie zeigt eine aktive, aber junge Entwicklung: vite-plugin-satteri v0.3.5 erschien am 19. August 2026, nur Stunden nach v0.3.4 und v0.3.3 am selben Tag. Diese Häufung deutet auf laufende Nachbesserungen hin. Versionsnummern unter 1.0 bedeuten, dass sich die API ohne Vorwarnung ändern kann.

Wer das Plugin einsetzt, sollte die genaue Version im Lockfile festhalten, weil die npm-Pakete und Rust-Crates gemeinsam weiterentwickelt werden. Eine Mischung aus aktueller Crate- und älterer Plugin-Version ist im README nicht abgedeckt; die Installationshinweise dafür stehen in der Dokumentation unter satteri.bruits.org/docs/installation.

satteri-plugin-api: Plugins in Rust und JavaScript

Das Plugin-Modell verläuft auf zwei Ebenen. In Rust definiert das Crate satteri-plugin-api ein Plugin-Trait mit typisierten Besuchern und einem Runner. Rust-Plugins erhalten damit direkten Zugriff auf die Syntaxbäume, ohne Umweg über JavaScript, was für Transformationen sinnvoll ist, die ohnehin dort arbeiten wollen.

Die zweite Ebene ist die TypeScript-Schicht im npm-Paket satteri, über die JavaScript-Plugins entstehen. Das folgt dem unified-Modell, in dem remark und rehype ebenfalls über Besucherfunktionen auf Bäumen arbeiten. Wer also bereits remark-Plugins geschrieben hat, kann das Muster wiederverwenden, muss aber die konkrete API-Schnittstelle in der Dokumentation nachschlagen, denn das README spezifiziert sie nicht.

Der Kompromiss ist klar erkennbar: Parsen und Kompilieren laufen in Rust, Plugin-Code bleibt in JavaScript. Das hält die Einstiegshürde niedrig, bedeutet aber auch, dass Plugins die schnelle Pipeline bei jedem Besuch erneut verlassen und zurückkehren.

Reifegrad von Sätteri: Zahlen, Lücken, Alternative

Die Repository-Metadaten zeigen 1.209 Sterne, 33 Forks und 34 offene Issues bei einem letzten Push am 19. August 2026. Das Projekt ist nicht archiviert, und die drei Releases vom August 2026 belegen kontinuierliche Arbeit. Die Bezeichnung High-performance im README ist allerdings eine Selbstaussage; konkrete Benchmark-Zahlen gegenüber remark oder reinem mdxjs-rs nennt das README nicht.

Eine echte Lücke: Der Zeitpunkt, an dem JavaScript-Plugins in der Pipeline ausgeführt werden, lässt sich aus dem README nicht ableiten. Wer von remark migriert und Plugin-Verhalten auf MDAST erwartet, muss im Playground oder in der API-Referenz prüfen, ob das Ergebnis identisch ausfällt. Auch Fehlerbehandlung der MDX-Kompilierung wird im README nicht beschrieben.

Als Alternative bleibt das klassische unified-Ökosystem mit remark, rehype und dem Original-mdxjs-rs. Es läuft komplett in JavaScript, bietet das deutlich größere Plugin-Angebot und keine NAPI-Grenze. Der Unterschied zu Sätteri liegt genau in der Trennung: remark gibt maximale Ökosystemkompatibilität gegen Geschwindigkeit, Sätteri nimmt Fork-Risiko in Kauf und verschiebt Parsing und Kompilierung nach Rust.

Redaktionelles Fazit

Sätteri passt für Teams, die in Vite arbeiten und große Mengen an .md- und .mdx-Inhalten verarbeiten, ohne das unified-Plugin-Modell aufzugeben. Weniger geeignet ist es für Projekte, die die vollständige remark/rehype-Plugin-Vielfalt brauchen oder auf stabile 1.0-Versionen angewiesen sind, denn die Pakete stehen noch am Anfang. Vor der Übernahme lohnt ein Blick in den Playground auf satteri.bruits.org und ein Test mit dem eigenen Inhaltsbestand über vite-plugin-satteri, ob die Ausgabe der Pipeline dem bisherigen remark-Ergebnis entspricht.

Offizielle Quellen

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Community-Notizen

Community-Notizen