doocs/md: WeChat-Markdown ohne Nachbearbeitung im Editor

Warum das Projekt existiert: WeChat akzeptiert kein rohes Markdown

Der öffentliche Account von WeChat nimmt keinen Markdown-Text entgegen. Wer dort schreibt, fügt Absätze, Überschriften und Bilder in einen Rich-Text-Editor ein und richtet das Ergebnis danach Stück für Stück ein. Genau an dieser Stelle setzt doocs/md an: Das README beschreibt den Kern in einem Satz, Markdown-Dokumente werden automatisch und unmittelbar in ein WeChat-Layout gerendert, damit die Formatierung nicht mehr die Hauptarbeit ist. Die Zielgruppe sind Autorinnen und Autoren, die den Text in Markdown schreiben und das fertige Layout nur noch in den Account kopieren. Das ist eine engere Zielgruppe, als der Name vermuten lässt. Ein Markdown-Editor für beliebige Ziele wäre ein anderer Artikel; hier ist das Ausgabeformat der Zweck des Projekts, und alle Funktionen hängen daran.

Vom Markdown zum eingefügten Artikel: was im Browser passiert

doocs/md ist eine Web-Anwendung, gebaut mit Vue 3, Vite und Tailwind CSS, wie die Themenliste des Repositories zeigt. Der Editor läuft im Browser, das Rendering ebenfalls; die Seite md.doocs.org ist die gehostete Instanz, und das README empfiehlt ausdrücklich Chrome für die beste Erfahrung. Ein Server ist für den Grundbetrieb nicht nötig. Die Verarbeitungskette ist aus den Funktionen ablesbar: Markdown wird geparst, mathematische Formeln gehen an KaTeX, Mermaid- und PlantUML-Blöcke werden als Diagramme gerendert, GFM-Warnblöcke und eine Ruby-Erweiterung in der Form [Text]{Anmerkung} kommen hinzu. Anschließend legt eine Theme-Schicht das Ergebnis in WeChat-taugliches Markup, das sich in den Editor des Accounts einfügen lässt. Bilder bleiben zunächst lokal und werden erst beim Upload in ein konfiguriertes Ziel überführt. Diese Trennung ist wichtig, weil sie erklärt, warum die Anwendung ohne Anmeldung benutzbar ist: Entwürfe liegen im Browser, nicht auf einem Server des Projekts.

Installation und die Konfigurationsschlüssel der Bildziele

Das Repository nennt drei Wege. Der einfachste ist die gehostete Instanz unter md.doocs.org. Für den lokalen Betrieb gibt es ein Docker-Image unter doocs/md auf Docker Hub sowie ein npm-Paket @doocs/md-cli; das README verlangt Node >= 22, was ältere CI-Umgebungen ausschließt. Die eigentliche Konfigurationsarbeit steckt in den Bildzielen, und die Parameter sind pro Anbieter unterschiedlich. GitHub braucht Repo und Token. Die Alibaba Cloud OSS erwartet AccessKey ID, AccessKey Secret, Bucket und Region. Tencent COS verlangt SecretId, SecretKey, Bucket und Region. MinIO benötigt Endpoint, Port, UseSSL, Bucket, AccessKey und SecretKey. Cloudflare R2 will AccountId, AccessKey, SecretKey, Bucket und Domain. Der WeChat-eigene Bildspeicher verlangt appID, appsecret und eine Proxy-Domain. Wer kein Schema findet, das passt, kann den Upload über den Punkt 自定义上传 selbst implementieren, wie die Tabelle vermerkt. Bemerkenswert: Die Standardoption benötigt laut Tabelle keine Konfiguration, was für einen schnellen Test ausreicht, aber die Kontrolle über die Ablage beim Anbieter lässt.

Dreizehn Bildziele sind Stärke und Angriffsfläche zugleich

Die Liste der unterstützten Speicher umfasst GitHub, Alibaba Cloud OSS, Tencent COS, Qiniu Kodo, MinIO, S3-kompatible Dienste, den WeChat-Bildspeicher, Cloudflare R2, Upyun, Telegram, Cloudinary und einen eigenen Upload. Das ist eine bewusst breite Aufstellung, und sie hat einen Preis. Jeder Anbieter bringt eigene Felder mit, jedes Zugangsgeheimnis liegt im Browser, und die Fehlermeldungen der Anbieter sind unterschiedlich aussagekräftig. Wenn ein Upload still scheitert, ist die Ursache selten im Editor zu finden, sondern in einem falschen Bucket-Namen, einer abgelaufenen Region oder einem Token ohne Schreibrecht. Wer doocs/md einführt, sollte deshalb zuerst genau ein Ziel sauber konfigurieren und nicht mehrere parallel. Ein weiterer Punkt: Der Upload überträgt Bilder an einen Dienst, der nicht Teil des Projekts ist. Die Datenschutzfrage stellt sich also nicht bei doocs/md, sondern bei dem Bucket, den man selbst auswählt.

Grenzen: kein Plugin-System, keine Garantie für fremde Ausgabe

Das Projekt ist auf ein Ausgabeformat zugeschnitten. Wer aus demselben Markdown eine Website, ein PDF und einen Newsletter erzeugen will, bekommt hier nur den WeChat-Pfad. Ein Plugin-System für eigene Renderer ist im Material nicht erkennbar; Anpassungen laufen über die Theme- und CSS-Schicht, die das README als anpassbare Themenfarben und Stile beschreibt. Der zweite Vorbehalt betrifft die Langlebigkeit des Ergebnisses: Das eingefügte Markup hängt davon ab, welche Konstrukte der Editor von WeChat akzeptiert. Ändert die Plattform ihre Regeln, betrifft das die Ausgabe, und der Editor müsste nachziehen. Das ist kein Fehler des Projekts, sondern eine Eigenschaft jedes Werkzeugs, das für eine geschlossene Plattform rendert. Wer diese Abhängigkeit nicht eingehen will, sollte den Text stattdessen in einem neutralen Format halten und die WeChat-Fassung als eine von mehreren Ausgaben behandeln.

Was doocs/md von einem Markdown-Editor mit Export unterscheidet

Der naheliegende Vergleich ist ein Markdown-Editor wie Typora, der Markdown in HTML oder PDF ausgibt. Der Unterschied liegt nicht im Schreibkomfort, sondern im Ziel: Typora erzeugt eine Datei, die man selbst weiterverwendet, doocs/md erzeugt ein Fragment, das für die Einfügefläche eines bestimmten Editors gebaut ist. Deshalb sind Funktionen wie die dreizehn Bildziele und die Anmeldung mit Cloud-Synchronisierung dort sinnvoll und in einem lokalen Editor überflüssig. Der zweite Unterschied ist der Umfang der Auszeichnungssprache. doocs/md verarbeitet zusätzlich KaTeX-Formeln, Mermaid- und PlantUML-Diagramme, GFM-Warnblöcke und eine Ruby-Notation, die in einem allgemeinen Markdown-Werkzeug meist fehlen. Dafür fehlt die Freiheit, das Ausgabeformat selbst zu bestimmen. Wer beides braucht, betreibt zwei Werkzeuge und nicht eines.

Wartung, Releases und die Lizenzfrage

Das Repository ist nicht archiviert, der letzte Push liegt im September 2026, die jüngsten Releases sind v2.1.0 vom Oktober 2025, v2.0.4 vom Juni 2025 und v2.0.3 vom Mai 2025. Zwischen den Minor-Versionen liegen mehrere Monate, es handelt sich also nicht um einen täglich nachgeführten Zweig. Für die Planung heißt das: Wer die gehostete Instanz nutzt, bekommt Änderungen ohne eigenes Zutun; wer selbst baut, sollte vor einem Upgrade die Release-Notes lesen, weil Anpassungen an Themes und benutzerdefiniertem CSS bei einem Sprung auf eine neue Minor-Version brechen können. Die Lizenz ist WTFPL, eine permissive Lizenz ohne Bedingungen. Sie erlaubt praktisch jede Verwendung, auch kommerzielle, und verlangt keine Namensnennung und keine Offenlegung von Änderungen. Wer auf klare Haftungs- und Patentklauseln angewiesen ist, findet sie in diesem Lizenztext nicht, und für eine rechtliche Bewertung des eigenen Falls ist das nicht der richtige Ort. Praktisch relevant ist eher die Frage, ob die Anmeldung zur Cloud-Synchronisierung gewünscht ist: Ohne Konto bleiben Entwürfe im Browser, mit Konto wandern Editor-Einstellungen auf einen fremden Server.

Für wen sich der Einsatz lohnt und was vorher zu klären ist

Wer regelmäßig für den öffentlichen Account schreibt und den Text in Markdown verfasst, gewinnt hier den Schritt zurück in den Rich-Text-Editor. Wer dagegen freies HTML, eigene Komponenten oder einen Redaktionsworkflow mit Rollen und Freigaben braucht, wird mit einem Theme-System nicht glücklich. Vor der Übernahme sind drei Dinge zu klären: erstens, ob die eigene Umgebung Node >= 22 bereitstellt, falls aus dem Quelltext oder über @doocs/md-cli gebaut wird; zweitens, welches Bildziel verwendet werden soll und ob alle dafür nötigen Schlüssel vorliegen, weil ein falsch konfigurierter Bucket sich erst beim Upload zeigt und nicht beim Schreiben; drittens, ob die Entwürfe lokal bleiben sollen oder die Cloud-Synchronisierung genutzt wird. Ein sinnvoller erster Schritt ist die gehostete Instanz unter md.doocs.org mit einem einzigen Testartikel und genau einem Bildziel. Erst wenn dieser Durchlauf vom Markdown bis zum eingefügten Beitrag ohne Nacharbeit funktioniert, lohnt der eigene Build.

Redaktionelles Fazit

Für Redaktionen, die laufend WeChat-Artikel aus Markdown veröffentlichen und Bilder über einen eigenen Bucket ausliefern, ist doocs/md die passende Wahl, weil das Rendering und die dreizehn Upload-Ziele den manuellen Nachbau im WeChat-Editor überflüssig machen. Wer freies HTML, eigene Komponenten oder ein CMS mit Redaktionsworkflow braucht, sollte es nicht einsetzen. Vor der Übernahme zu prüfen sind die Node-Version (das README verlangt Node >= 22), die Konfigurationsschlüssel des gewählten Bildziels und die Frage, ob die Inhalte im Browser bleiben oder über die Anmeldung in die Cloud-Synchronisierung wandern.

Offizielle Quellen

1. doocs/md on GitHub
2. License: WTFPL
3. Project website
4. README
5. Releases