Doctor

blume doctor erkennt Konfigurations- und Inhaltsprobleme, bevor du baust – die Konfiguration, jede Seite, die Node-Version und Features, die einen Server brauchen.

blume doctor scannt das Projekt genau so, wie blume build es tun würde, und meldet, was es findet, ohne etwas zu generieren oder zu bauen. Führ es als Erstes aus, wenn ein Build aus einem nicht offensichtlichen Grund fehlschlägt. Außerdem eignet es sich als günstige Prüfung in der CI:

blume doctor

blume init fügt es außerdem als doctor-Skript zur package.json hinzu. Mit pnpm führst du es als pnpm run doctor aus (pnpm --filter <workspace> run doctor vom Root eines Monorepos aus): Ein bloßes pnpm doctor führt statt des Skripts den eingebauten doctor-Befehl von pnpm aus.

Was geprüft wird

Die Node-Version gegen den Bereich, den das installierte blume-Paket unterstützt. Dieser wird aus dem eigenen engines-Feld des Pakets gelesen. Liegt die Version außerhalb, gibt es eine Warnung: Es kann funktionieren, aber Blume testet diese Kombination nicht.
blume.config.ts, mit derselben Validierung, die auch ein Build durchführt. Ein entfernter oder umbenannter Schlüssel schlägt mit einem Hinweis auf seinen Ersatz fehl statt mit einem bloßen „unrecognized key“.
Jede Inhaltsseite und jede Ordner-Meta: die Diagnosen, die blume dev und blume build beim Laden des Projekts ausgeben – ungültiges Frontmatter, .mdx, das sich nicht parsen lässt, Navigationsprobleme, fehlende Include-Ziele und alles Weitere –, gesammelt in einem Bericht.
Navigation, die ins Leere führt: ein Tab, ein Selector-Eintrag, ein Featured-Link, eine Header-Aktion oder ein Call-to-Action, dessen Pfad zu keiner Seite, keiner eigenen .astro-Seite, keiner generierten Route, keiner Referenz, keiner Datei in public/ und keiner von Blume generierten Datei passt: eine Warnung (BLUME_NAV_MISSING_PAGE), dieselbe, die blume dev und blume build ausgeben. Ein Tab wird dort geprüft, wohin er verlinkt: über sein href, wenn er eines hat, sonst über seinen path.
<Component>-Beispiele, die nicht existieren: ein path, der keine Datei unter examples benennt und den die Seite als „No example found“-Box anzeigen würde: eine Warnung (BLUME_EXAMPLE_NOT_FOUND) in der entsprechenden Zeile, so wie blume dev und blume build sie ausgeben. Eine Überschreibung in components.ts oder ein Island namens Component ersetzt die eingebaute Komponente und wird nicht geprüft.
Features, die einen Server brauchen, auf einer Site, die für statische Ausgabe konfiguriert ist – der Assistent, der MCP-Server, der eingebaute Proxy des Try-it-Playgrounds oder die Suche im Server-Modus (Mixedbread): ein Fehler, der das Feature benennt, zusammen mit dem Deployment-Adapter, zu dem du wechseln solltest (oder, wenn ein Host-Adapter auf output: "static" gesetzt ist, mit dem Hinweis, diese Option zu entfernen).
Pakete, die deine Konfiguration braucht, die aber nicht installiert sind – das SDK, das ein Such-, Content-Source-, Assistenten- oder Narrations-Adapter importiert, das @astrojs/*-Paket eines Deployment-Adapters oder der Renderer für Vue- oder Svelte-Islands: ein Fehler, der jedes Paket benennt, zusammen mit dem Installationsbefehl für deinen Paketmanager. blume build bricht bei derselben Prüfung ab.
Überschreibungen in components.ts, die Blume nicht einplanen kann – ein Inline- oder berechneter Eintrag oder ein Import, dessen Datei nicht existiert: jeweils ein Fehler in der entsprechenden Zeile.
Ein Ordner, der wie eine Version aussieht (v1.0/), auf einer Site ohne konfigurierte versions, der sonst als gewöhnlicher Inhalt gebaut würde: eine Warnung mit Verweis auf blume version.
Secrets, die ein aktiviertes Feature liest, die aber nicht gesetzt sind, etwa MIXEDBREAD_API_KEY oder OPENROUTER_API_KEY: eine Warnung, die die Variable benennt. Doctor lädt zuerst .env und .env.local, genau wie blume dev und blume build, und prüft, bevor eine entfernte Content-Source etwas abruft. So wird die Warnung auch dann ausgegeben, wenn eine Quelle anschließend ohne ihr Token fehlschlägt.

Die Zusammenfassung

Nach den Diagnosen gibt doctor aus, wie das Projekt aufgelöst wurde. So siehst du auf einen Blick, ob sich das, was du für konfiguriert hältst, von dem unterscheidet, was Blume sieht: die Seitenanzahl, der Ausgabemodus und der Deployment-Adapter, der Suchanbieter, die konfigurierten Referenz-, Analytics- und Content-Source-Adapter sowie ob der Assistent aktiviert ist und welches Backend er nutzt.

Exit-Code und JSON

Doctor beendet sich mit einem Exit-Code ungleich null, wenn es Fehlerdiagnosen gibt. Damit schlägt die CI bei denselben Problemen fehl wie ein Build. Warnungen werden gemeldet, lassen die CI aber nicht fehlschlagen. --json gibt die Diagnosen statt des Terminal-Berichts als JSON auf stdout aus, im selben Format, das blume validate --json verwendet.