✨ Highlights

Dieses Release schließt das langlaufende #175 (GitHub-Pages-Subpath-Assets 404 auf verschachtelten Seiten), vereinheitlicht die Navigation-Trailing-Slash-Behandlung über Projekttypen hinweg, bündelt MiniSearch lokal (sodass Keyword-Search ohne CDN funktioniert) und unterdrückt den duplizierten Auto-Install-Spam, der beim Ausführen von docmd in einem Verzeichnis ohne package.json erschien.

Keine Breaking Changes. Keine neue Konfiguration erforderlich. Bestehende Konfigurationen, Plugins und CI-Pipelines funktionieren unverändert.

🐛 Fix: Subpath-Deploy-Asset-Auflösung (#175)

Der 0.8.14-Ansatz kombinierte ein <base href>-Tag mit tiefenrelativen Asset-Pfaden (../../assets/...). Bei einem Subpath-Deploy (z. B. https://user.github.io/repo/) löste der Browser den tiefenrelativen Pfad gegen die <base>-URL auf, was das /repo/-Präfix entfernte und jedes Asset auf verschachtelten Seiten (/repo/guide/) mit 404 fehlschlug.

Der Fix: Subpath-Deploys emittieren jetzt root-relative Asset- und Navigations-URLs (/repo/assets/css/...) und das <base>-Tag wird für Non-Offline-Builds nicht mehr emittiert. Root-relative Pfade lösen sich korrekt auf jeder Seitentiefe auf, funktionieren mit fetch() und SPA-Navigation und brechen keine Hash-Anker auf verschachtelten Seiten. Offline-Builds behalten ihr bestehendes tiefenrelatives + index.html-Design unangetastet.

🧹 Fix: Navigation-Trailing-Slash-Konsistenz

In Non-i18n-Projekten mit lokaler navigation.json ließen Sidebar- und Prev/Next-Links den Trailing-Slash weg (./guide), während Markdown-Body-Links ihren Slash behielten (./guide/). Die lokale navigation.json wurde nach dem Normalisierungs-Durchlauf geladen, sodass ihre Pfade den zentralisierten normalizeNavPaths-Schritt umgingen.

Der Fix: die lokale navigation.json wird jetzt zur Ladezeit normalisiert, passend zur Behandlung, die geerbte Config-Navigation und auto-generierte Navigation bereits erhielten. Alle Navigationsoberflächen stimmen jetzt in der Trailing-Slash-Konvention überein.

🔒 Gebündeltes MiniSearch (Keine CDN-Dependency)

Keyword-Search lud zuvor MiniSearch zur Laufzeit von cdn.jsdelivr.net. Das brach Search in Air-Gapped-Umgebungen, hinter Unternehmens-Firewalls und während der sandboxed Browser-Test-Suite.

Der Fix: MiniSearch wird jetzt zur Build-Zeit von node_modules nach site/assets/js/vendor/minisearch.js kopiert - dieselbe Asset-Pipeline, die von docmd-search.js, docmd-git.js und anderen Plugin-Bundles verwendet wird. Die Version wird dynamisch vom installierten Paket gelesen, sodass sie automatisch synchron bleibt. Das CDN wird nur als letzte Notlösung beibehalten, falls die lokale Auflösung fehlschlägt.

Das fügt dem veröffentlichten @docmd/plugin-search-Paket null Gewicht hinzu: MiniSearch war bereits eine deklarierte Runtime-Dependency, nur nicht in den Output gebündelt.

🧹 Auto-Install-Output de-dupliziert

Zwei Probleme erzeugten verrauschten, repetitiven Output beim Ausführen von docmd in einem Verzeichnis ohne package.json:

1. Worker-Thread-Duplikation: der Worker-Pool der Build-Engine (ein Thread pro Kern) versuchte jeweils dasselbe fehlende Plugin zu auto-installieren und druckte dieselbe Fehlermeldung N-mal.
2. Fehlende package.json: ohne Projekt zum Installieren lehnte jeder Paketmanager ab - aber docmd meldete jede Ablehnung als opaken “unknown error”, einmal pro fehlendem Plugin.

Der Fix:

• Worker-Threads überspringen Auto-Install nun vollständig (nur der Main-Thread hat Schreibzugriff auf node_modules und das Terminal des Users).
• Eine fehlende package.json produziert einen einzelnen, handlungsorientierten Hinweis auf npx @docmd/core init, statt einer Wand von Spawn-Fehlern.

Migration

Null. Bestehende Konfigurationen, Plugins und CI-Pipelines funktionieren unverändert.

Vollständiges Changelog: https://github.com/docmd-io/docmd/compare/0.8.14...0.8.15