Prettier 3.9 überholt fünf Parser: micromark für Markdown, yaml v2, GraphQL.js v17, ein Rust-basierter Flow-Parser und Angular

Prettier 3.9 überholt fünf Parser: micromark für Markdown, yaml v2, GraphQL.js v17, ein Rust-basierter Flow-Parser und Angular

lschvn

Prettier 3.9.0, veröffentlicht am 27. Juni 2026 in einem 37-minütigen Blogpost von Fisker Cheung, ist ungewöhnlich für ein Prettier-Release: Die Schlagzeile ist keine neue Config-Option und kein schnelleres CLI, sondern fünf Parser-Upgrades, die gleichzeitig landen. Markdown, YAML, GraphQL, Flow und Angular wechseln alle zu neueren Upstream-Parsern, und der JavaScript- und TypeScript-Printer wird überarbeitet, was in den meisten Repos als Diff auftauchen wird. Wer die Prettier-Ausgabe als stabil betrachtet, sollte 3.9 gezielt einführen und die genaue Version festpinnen.

Fünf Parser, eine Version

Die Markdown-Änderung werden die meisten Nutzer spüren. Prettiers Markdown-Parser wechselt vom veralteten remark-parse v8 zu micromark v4, dem modernen CommonMark-Parser. Die Release-Notes beschreiben das als „deutlich verbesserte CommonMark- und GFM-Konformität" plus „zahlreiche lange bestehende Parsing-Bugs" behoben und schafft eine sauberere Grundlage für künftige Arbeit. Ein Vorbehalt: Die Migration des MDX-Parsers ist noch nicht abgeschlossen, und das Team bittet Mitwirkende, die mit dem unified-Ökosystem und micromark vertraut sind, sie abzuschließen.

YAML wechselt zu yaml v2, was viele lange bestehende Parsing-Probleme behebt, mit Dank an ota-meshis Arbeit am yaml-unist-parser. GraphQL wechselt zu GraphQL.js v17, das neuere Syntax unterstützt: Fragment-Argumente (...dynamicProfilePic(size: $size)) und Direktiven auf Direktivdefinitionen sowie extend directive, die beide auf 3.8 einen Fehler oder falsches Parsing verursachten.

Das Flow-Upgrade ist die Performance-Geschichte. Prettier verwendet jetzt den neuen (oxidized) Rust-basierten Flow-Parser des Flow-Teams. In Prettiers lokalen Parser-only-Benchmarks formatierte der neue Parser Prettiers gültige Flow-Fixtures in einem Median von 266,4 ms gegenüber 422,6 ms beim alten Parser und parsed flow_parser.js in 1298,0 ms gegenüber 2269,6 ms. Das ist rund 37 % bzw. 43 % schneller und ist dieselbe Richtung nativer Rust-Frontends, die das Projekt über seine OXC- und Hermes-Plugins erkundet hat und die das breitere Ökosystem mit Oxc und SWC einschlägt.

Der JavaScript- und TypeScript-Printer hat sich geändert

Die Parser-Upgrades sind die Hälfte der Version; die andere Hälfte ist eine Reihe von Printer-Änderungen, die einen Diff erzeugen. Die auffälligste ist ein lange bestehender Idempotenz-Bug im --no-semi-Modus. Auf 3.8 erzeugte ein break oder continue gefolgt von einem Zeilenkommentar unterschiedliche Ausgabe beim ersten und zweiten Durchlauf, sodass zweimaliges Ausführen von Prettier die Datei immer wieder verändern konnte. Auf 3.9 ist die Kommentarbehandlung um break und continue über Durchläufe hinweg stabil.

Eine kurze Liste der weiteren Printer-Änderungen:

  • Redundante Klammern entfernt in return-Anweisungen, sodass return (a, b) nicht mehr zu return ((a, b)) umgeschrieben wird.
  • Eingebettete Template-Interpolationen neu ausgerichtet in getaggten Templates, unerwartete Zeilenumbrüche werden vermieden und die Ausrichtung in CSS-in-Template-Literal-Blöcken korrigiert.
  • Inlining logischer Negationen: !(...) in if/while/do..while-Bedingungen wird inlined, um den Diff zu reduzieren, wenn eine Bedingung in ihren negierten Wert kippt; das behebt einen realen Doppel-Klammer-Fall innerhalb des Prettier-Codebasen selbst.
  • Nachstehende Doppel-Leerzeichen im JSDoc erhalten, weil manche Tools sie als bedeutsam behandeln.
  • Kommentar-Platzierung um leere Aufruf-Argumentlisten und geklammerte Callees korrigiert.

Nichts davon ist eine Config-Änderung, aber zusammen bedeuten sie, dass ein prettier --write . nach dem Upgrade Dateien neu formatiert.

Der echte Breaking Change: Import-Assertions

Die Version entfernt die Unterstützung für die veraltete import ... assert {}-Syntax:

- import foo from "./foo.json" assert { type: "json" };
+ import foo from "./foo.json" with { type: "json" };

Der Grund liegt upstream: Babel 8 hat die Unterstützung für das veraltete assert-Schlüsselwort komplett entfernt (das alte Parser-Plugin ist weg), und ohne Babel-Parser-Support kann Prettier diese Syntax nicht mehr zuverlässig parsen oder formatieren. Der aktuelle Standard ist das with-Schlüsselwort aus dem Import-Attributes-Proposal. Wer noch assert verwendet, sollte vor dem Upgrade migrieren; Prettier verweist auf seinen Hinweis zu nicht standardmäßiger Syntax als Kontext.

CLI-Fixes, die man kennen sollte

Einige CLI-Fixes runden die Version ab. --cache-strategy content war stillschweigend defekt: file-entry-cache v11 benannte die Option useChecksum in useCheckSum (großes S) um, und Prettier übergab noch die alte Schreibweise, sodass der inhaltsbasierte Cache-Vergleich deaktiviert war und nur die Dateigröße verglichen wurde. Das ist nun behoben, sodass inhaltsbasiertes Caching wieder funktioniert.

Prettier sucht außerdem nicht mehr nach EditorConfig-Dateien oberhalb von Git-Worktrees: Eine .git-Datei (genutzt in Worktrees und Submodulen) wird jetzt als Projekt-Root-Marker behandelt, ebenso wie ein .git-Verzeichnis, sodass eine EditorConfig aus einem übergeordneten Verzeichnis nicht mehr in die Worktree-Formatierung einsickert. Zwei Crash-Fixes behandeln Verzeichnis- und Dateinamen mit Sonderzeichen (eckige Klammern wie username[repo-name] und führende Anführungszeichen), und die experimentelle CLI erhält Updates.

Was man beobachten sollte

Der praktische Rat ist einfach: Pinnen Sie die genaue Version fest. Die Release-Notes wiederholen die stehende Empfehlung, "prettier": "3.9.0" statt ^3.9.0 zu verwenden, weil die Markdown-, YAML-, GraphQL- und JS/TS-Änderungen alle Ausgabe-Diffs erzeugen und eine Caret-Range ein neues Minor ziehen kann, das bei einer Neuinstallation ein ganzes Projekt neu formatiert. Wer @prettier/plugin-oxc oder @prettier/plugin-hermes nutzt, sollte sie zeitgleich aktualisieren, damit die neuen Formatierungsregeln greifen.

Zwei Dinge vor dem Upgrade testen: jegliche Markdown- oder MDX-Dokumentation (der micromark-Wechsel ist die breiteste Änderung) und jeglichen Flow- oder GraphQL-lastigen Code. Die MDX-Migration ist noch offen, sodass insbesondere die MDX-Ausgabe einen sorgfältigen Diff verdient. Das vollständige Changelog steht in der Compare-Ansicht, und 3.9.1 folgte am selben Tag mit Nachbesserungen.

Häufig gestellte Fragen

Cline 4.0 migriert die VS-Code-Erweiterung auf das gemeinsame Cline SDK und ergänzt ClinePass, einen Customize-Marktplatz, Plugins und Warteschlangen-Prompts

Cline hat v4.0.0 am 26. Juni 2026 veröffentlicht (github.com/cline/cline), eine Hauptversion, die die VS-Code-Erweiterung von ihrer eigenständigen Legacy-Task-Implementierung auf das gemeinsame Cline SDK migriert, dieselbe TypeScript-Engine, die auch die Cline-CLI, Kanban und das JetBrains-Plugin antreibt. Die Version fügt ClinePass (integriertes Onboarding, Provider-Auswahl, Abonnement-Übergabe und Berechtigungsverwaltung) hinzu, einen Customize-Marktplatz für Skills, MCP-Server und die neuen Cline Plugins, Warteschlangen-Prompts, Bearbeiten-und-Regenerieren, eine Überarbeitung der Provider- und Modellkonfiguration rund um providers.json und einen gemeinsamen Modellkatalog (Fireworks GLM 5.2, Kimi K2.6 Fast, Kimi K2.7 Code, Qwen 3.7 Plus, MiniMax M3, SAP AI Core, LiteLLM, Codex OAuth), standardmäßig deaktivierte Befehls-Auto-Genehmigung und einen auf Bun umgestellten Build- und Package-Workflow der Erweiterung. Subagenten sind in der Erweiterung vorübergehend deaktiviert, während das SDK-basierte Erlebnis stabilisiert wird.

Cline 4.0.1 setzt die SDK-Migration nach den Regressionen in 4.0.0 zurück; 4.0.2 bringt den SDK-Code mit Reasoning-Effort- und ClinePass-Fehlerbehebungen zurück

Cline hat v4.0.1 am 28. Juni 2026 und v4.0.2 am 29. Juni 2026 (github.com/cline/cline) veröffentlicht, einen zweistufigen Wiederherstellungszyklus für die SDK-Migration in v4.0.0, die am 26. Juni ausgeliefert wurde. v4.0.1 liefert die VS Code-Erweiterung 3.89.x aus der Zeit vor dem SDK unter einer 4.0.1-Versionsnummer aus, gebaut aus einem dedizierten `legacy-extension`-Branch über einen neuen `ext-vscode-publish-legacy.yml`-Workflow, um die in 4.0.0 gemeldeten Regressionen zu beheben (kaputte Diff-Vorschauen im Editor, run_commands-Fehler bei Dateibearbeitungen, kaputter Dateibearbeitungs-Flow mit GLM 5.2 und MiniMax M3 über Ollama). v4.0.2 stellt den SDK-basierten Codepfad auf demselben Legacy-Branch wieder her und fügt Reasoning-Effort-Unterstützung (inklusive `xhigh`) für DeepSeek-Thinking-Modelle hinzu (#11938), eine zentralisierte Reasoning-Effort-Steuerungsschicht für ClinePass (#11954), kanonische Z.ai-Modell-IDs (#11951), einen Webview-Env-Ersetzungs-Fix (#11955), eine Politur der ClinePass- und Z.ai-Metadaten (#11958) und einen Fix für die Focus-Chain-Standardeinstellungen (#11960). Die CLI v3.0.32 erscheint am selben Tag mit Kontextverdichtungs-Verbesserungen aus SDK v0.0.54 und ClinePass-Onboarding-Politur. Die Veröffentlichungssequenz zeigt ein Projekt, das eine große Migration in 72 Stunden wiederherstellt, indem es den Legacy-Branch vorrollt, anstatt die SDK-Arbeit rückgängig zu machen.

Verwandte Artikel

Weitere Berichterstattung zu ähnlichen Themen und Tags.

Biome 2.5 liefert `@biomejs/js-api` v6.0.0: ein Major-Bump für die JS-API
tooling

Biome 2.5 liefert `@biomejs/js-api` v6.0.0: ein Major-Bump für die JS-API

Biomes CLI erreicht 2.5.0 und die JavaScript-API springt auf ein v6.0.0-Major. Die Schlagzeile ist der neue spanInBytesToSpanInCodeUnits-Helper, der einen echten UTF-16-Surrogate-Bug bei der Extraktion von nicht-ASCII-Diagnosetext behebt, plus eine lange Liste an SCSS-, JSON-, Linter- und CLI-Verbesserungen.
Vite+: Eine CLI zum Herrschen, Oder nur eine weitere Ebene des Hypes?
tooling

Vite+: Eine CLI zum Herrschen, Oder nur eine weitere Ebene des Hypes?

VoidZeros Vite+ verspricht, Runtime, Paketmanager, Bundler, Linter, Formatter und Test-Runner unter einem einzigen Befehl zu vereinen. Wir haben die Ankündigungen gelesen, die Behauptungen benchmarkt und mit Menschen gesprochen, die es in Produktion nutzen.
Turborepo 2.10.3 Erkennt nub und aube, Zwei Neue Rust-basierte Node.js-Paketmanager von Colin McDonnell (Zod) und Jeff Dickey (mise)
tooling

Turborepo 2.10.3 Erkennt nub und aube, Zwei Neue Rust-basierte Node.js-Paketmanager von Colin McDonnell (Zod) und Jeff Dickey (mise)

Turborepo [v2.10.3](https://github.com/vercel/turborepo/releases/tag/v2.10.3) wurde am 2026-07-03 mit First-Class-Support für [nub](https://github.com/nubjs/nub) und [aube](https://github.com/jdx/aube) veröffentlicht, zwei Rust-basierten Node.js-Paketmanagern, die im Frühjahr und Sommer 2026 entstanden sind. nub stammt von Colin McDonnell (Schöpfer von [Zod](https://github.com/colinhacks/zod), 43k Sternen) und aube von Jeff Dickey (Schöpfer von [mise](https://github.com/jdx/mise)); beide integrieren sich in Turborepo als `packageManager`-Werte in `package.json` und `devEngines.packageManager`. Die Release liefert außerdem einen neuen TUI/Streamed-Logs-Toggle, Click-to-Select für Tasks in der TUI-Taskliste, automatisches Kopieren von TUI-Selektionen in die Zwischenablage bei Maus-Release, ein `--production`-Flag auf `turbo prune`, TypeScript 7.0.1-rc als Workspace-Toolchain, Thin LTO + `codegen-units=1` für Release-Builds und eine lange Liste von Cache-Hashing-Performance-Fixes. Das Hauptsignal: Zwei der angesehensten Builder des JS-Toolchains liefern nun Paketmanager, die auf Stock-Node aufsetzen statt es zu ersetzen, und Turborepo ist das erste Mainstream-Monorepo-Tool, das beide formalisiert.

Kommentare

Anmelden Melden Sie sich an, um an der Diskussion teilzunehmen.

Noch keine Kommentare. Seien Sie der Erste, der seine Gedanken teilt.