Die docmd 0.8.0 Version stellt ein monumentales Architektur-Upgrade dar - sie führt einen nativen Multi-Threaded Worker-Pool ein, der Seiten parallel verarbeitet, wodurch die Build-Zeiten für große Dokumentations-Websites drastisch verkürzt werden, zusammen mit einer leistungsstarken neuen Plugin-Worker-API.

✨ Highlights

⚡ Multi-Threaded Build-Architektur

docmd baut Ihre Dokumentation jetzt parallel auf, indem ein hochoptimierter WorkerPool verwendet wird. Indem der schwerste Teil der Pipeline - das Parsing des Markdown-AST und die Prozessor-Hooks - in isolierte Hintergrund-Threads verlagert wird, kann docmd nun alle verfügbaren CPU-Kerne vollständig ausnutzen.

Für große Workspaces (z.B. mehr als 1000 Seiten) führt dies zu massiven Leistungsschüben, wodurch Kaltstart-Build-Zeiten drastisch verkürzt und die Entwicklererfahrung beim Hot-Reload flüssiger wird. Der Thread-Pool wird intelligent begrenzt (os.cpus().length - 1), um sicherzustellen, dass Ihr Hauptsystem bei schweren Builds reaktionsfähig bleibt.

🔌 Plugin Worker API

Wir haben docmd nicht nur multi-threaded gemacht, wir haben das Multi-Threading auch für das gesamte Ökosystem zugänglich gemacht.

Plugins können nun ihre eigenen rechenintensiven oder synchronen Aufgaben an den docmd-Worker-Pool auslagern, ohne die Thread-Erstellung selbst verwalten zu müssen. Eine neue runWorkerTask-API wird in ActionContext, PageContext und PostBuildContext injiziert.

export default {
  plugin: { name: 'my-plugin', version: '1.0.0', capabilities: ['post-build'] },
  
  async onPostBuild(ctx) {
    // Senden Sie schwere Vorgänge (wie das Parsen des Git-Verlaufs) an einen Hintergrund-Thread
    const result = await ctx.runWorkerTask(
      '/absolute/path/to/my-worker-script.js', 
      'parseGitHistory', 
      [ctx.outputDir]
    );
  }
}

🧩 Gemeinsamer modularer Kern

Wir haben formell ein neues Paket extrahiert: @docmd/utils, eine abhängigkeitsfreie Bibliothek für gemeinsam genutzte Dienstprogramme. Dieses Paket zentralisiert Dateisystem-Wrapper, Pfad-Normalisierung, Hashing-Mechanismen und den eigentlichen WorkerPool, verhindert zirkuläre Abhängigkeiten und ermöglicht es Plugins, robuste Hilfsmittel direkt aus dem docmd-Ökosystem zu importieren.

📝 Vollständiges Änderungsprotokoll

🚀 Engine & Architektur

  • Worker-Parser-Pipeline: Der Markdown-Kernprozessor wird nun dynamisch in Hintergrund-Threads rehydriert. Dateien werden gleichzeitig gelesen und chargenweise an die Worker verteilt.
  • AST Caching Engine: Eine MD5-basierte Caching-Ebene fängt unveränderte Dateien ab. Wenn sich der rohe Inhalts-Hash einer Datei seit dem letzten Durchlauf nicht geändert hat, wird das AST-Parsing komplett übersprungen.
  • Persistente Dev-Worker: Während docmd dev bleibt der Worker-Pool über Dateispeicherungen hinweg persistent. Dies eliminiert die typische Node.js-Thread-Startlatenz von 200-500 ms und führt zu nahezu sofortigen inkrementellen Rebuilds.
  • Worker CPU Throttling: Der Thread-Pool berechnet die exakte Anzahl der Threads basierend auf der Systemarchitektur und reserviert einen CPU-Kern, um I/O-Aushungerung und Betriebssystem-Sperren zu verhindern.

🔌 Plugin System

  • runWorkerTask API: Wird direkt in den Plugin-Kontexten (onBeforeRender, onPostBuild, actions, events) für die generische Skriptausführung im Hintergrund offengelegt.
  • Git Plugin Persistenter Cache: Das Git-Plugin nutzt nun einen robusten persistenten Festplatten-Cache (.docmd/cache/git-history.json), der über die Datei-Änderungszeit (mtimeMs) invalidiert wird. Dadurch werden redundante git log Shell-Subprozesse bei Folge-Builds vollständig eliminiert, was die Build-Zeit großer Repositories (800+ Seiten) von ~18 Sekunden auf nur noch ~3,5 Sekunden senkt.
  • Entkoppelte API-Importe: Plugins können nun fsUtils, WorkerPool und getGitRoot direkt von @docmd/utils importieren.

⚙️ Infrastruktur & Tools

  • Zentralisierter Git-Kontext: Die interne Git-Zweig-Erkennung und das Parsen des Repository-Stammverzeichnisses (getGitRoot) wurden in einen sicheren Hilfsbereich extrahiert.
  • JSON-serialisierbare Konfigurationen: Kontinuierlicher Übergang zur Zero-Config-Architektur durch Sicherstellung, dass das aufgelöste Konfigurationsobjekt vollständig JSON-serialisierbar ist, sodass es sicher in die Worker-Threads übertragen werden kann.

⚠️ Wichtige (Breaking) Änderungen

  • Kern-Modul-Importe: Wenn sich Ihre benutzerdefinierten Plugins auf tiefe relative Importe von @docmd/core/src/utils/fs-utils verlassen haben, müssen Sie diese Importe auf @docmd/utils aktualisieren.
  • Worker-Ausführungskontext: Plugins, die sich in das markdownSetup einklinken, müssen sicherstellen, dass ihre Erweiterungen vollständig serialisierbar sind, da Markdown-it-Prozessoren jetzt über Thread-Grenzen hinweg instanziiert werden.

Upgrade-Anleitung

Führen Sie ein Upgrade durch, indem Sie npm install docmd@latest ausführen. Dann:

  1. Testen Sie Ihre benutzerdefinierten Plugins: Wenn Sie ein benutzerdefiniertes docmd-Plugin pflegen, das AST manipuliert oder viel CPU-Zeit benötigt, prüfen Sie, ob Sie die neue runWorkerTask nutzen können, um die Build-Schleife schnell zu halten.
  2. Entfernen Sie manuelle Kern-Importe: Ersetzen Sie import { fsUtils } from '@docmd/core/dist/utils/fs-utils' durch import { fsUtils } from '@docmd/utils'.

Eine vollständige Anleitung finden Sie unter Erste Schritte - Installation.

next Übersicht