Oxlint apps_v1.72.0 und oxfmt apps_v0.57.0 sind am Abend des 29. Juni 2026 zusammen erschienen, auf Basis von crates_v0.138.0. Dieses Release ist der v0.138-Zyklus, den die v1.71-Versionsnotizen explizit vorausgesagt haben: « das letzte Apps-Release vor dem crates-v0.138-Release, das am Montag, dem 29.06.2026, erscheinen wird ». Der Zyklus schließt die AstBuilder-Migration ab, die seit den Versionen v0.135 bis v0.137 lief, entfernt den Prettier-Fallback für CSS / LESS / SCSS und GraphQL in oxfmt und liefert die größte einzelne Performance-Eintragung der v0.137 → v0.138-Strecke: die value_type-Memoisierung, die eine arithmetische Additionskette mit 20 000 Gliedern von 6,1 Sekunden auf 4,7 Millisekunden bringt.
Dieser Artikel behandelt das Oxlint-v1.72.0-Apps-Release, das Oxfmt-v0.57.0-Apps-Release und das crates-v0.138.0-Release zusammen, da die drei als Einheit konzipiert sind. Oxlint und Oxfmt ziehen die neueste crates-Linie zum Release-Zeitpunkt, und die Breaking Changes in diesem Zyklus sind in der crates-Schicht konzentriert.
AstBuilder-Vereinheitlichung: Die Migration v0.135 → v0.138 kommt an
Die größte Geschichte des v0.138-Zyklus ist die Vereinheitlichung der alten und neuen AstBuilder-APIs im oxc_ast-Crate. Die Migration läuft seit mindestens v0.135 Anfang Juni und ist die größte interne API-Änderung, die Oxc seit der Umschreibung des Minifiers vorgenommen hat.
Das Muster sind fünf PRs in diesem Release, die die API-Oberfläche zu einem einzigen Builder verschieben. #23876 (overlookmotel) beschränkt das Modul oxc_ast::builder darauf, nur den Typ AstBuilder und die Sentinelle NONE zu exportieren. #23834 (overlookmotel) wechselt oxc_ecmascript zum neuen AstBuilder. #23831 (overlookmotel) wechselt den Transformer zum neuen AstBuilder. #23875 (overlookmotel) entfernt die interne Duplizierung durch Vereinheitlichung der Builder. #23877 (overlookmotel) markiert die Legacy-AstBuilder-Methoden als #[deprecated]. Der Zyklus fügt auch ein Cargo-Feature-Flag disable_old_builder für oxc_ast hinzu (#23886, #23888), damit nachgelagerte Crates das Flag aktivieren und sehen können, was bricht, bevor die Legacy-Methoden entfernt werden.
Die Allocator-Seite erhält ihre eigene Charge von Änderungen. #23675 (overlookmotel) benennt das Trait AllocatorAccessor in GetAllocator um. #23676 (overlookmotel) lässt GetAllocator::allocator &self statt self annehmen. #23781 (overlookmotel) lässt Str- und Ident-Methoden &GetAllocator annehmen. Zusammen schließen die drei Änderungen die Migration zu einer ausleihenden Allocator-API ab: Aufrufer müssen einen Allocator nicht mehr klonen oder besitzen, um Strings und Identifier zu konstruieren.
Für Oxlint- und Oxfmt-Nutzer ist davon nichts sichtbar. Für nachgelagerte Crates, die benutzerdefinierte AST-Schichten auf Oxc aufbauen, ist dies die größte Breaking Change in drei Zyklen. Die Versionsnotizen markieren das Migrationsfenster: Legacy-Methoden tragen jetzt #[deprecated]-Annotationen, werden mit Warnungen kompilieren und werden in einem zukünftigen Zyklus entfernt. Das Team hatte dies seit zwei Zyklen signalisiert, wobei die v0.137-Versionsnotizen bereits vor der Breaking Change in oxc_ast warnten.
Die herausragende Performance-Eintragung: value_type-Memoisierung macht O(n²) zu O(n)
Die größte nutzerseitig sichtbare Performance-Eintragung in v0.138 ist PR #23929 (Dunqing): perf(minifier): memoize value_type to remove its O(n^2) re-walk on long binary chains. Das Post-Order-Peephole des Minifiers wertet Expression::value_type an jedem Knoten aus, und bei einer langen linksassoziativen binären Kette durchläuft die Auswertung erneut den gesamten linken Teilbaum (to_primitive → value_type → to_primitive → …). Für N Knoten betrugen die Gesamtkosten O(N²), und der dominante Fall sind nicht faltbare arithmetische Additionsketten: Eine a + a + … + a-Kette mit 20 000 Gliedern brauchte 6 118 ms zum Minifizieren, während die Parse- und Semantikphasen linear waren.
Der Fix memoisert value_type per Knotenadresse auf MinifierState, mit einem einzigen Schnittpunkt an der rekursiven Methode Expression::value_type. Jeder Knoten wird einmal berechnet, sodass die Gesamtkosten amortisiert O(N) werden. Der Cache wird als opt-in-Hooks auf GlobalContext (cached_value_type / cache_value_type) bereitgestellt, und nur der TraverseCtx<MinifierState> des Minifiers liefert einen echten Cache. Jeder andere Aufrufer (WithoutGlobalReferenceInformation, der Constant-Evaluation-Pass, Side-Effects-Analyse, das value_type-Unit-Harness) behält das exakte vorherige, nicht-cachte Verhalten. Der Cache wird am einzigen Mutations-Chokepoint (record_mutation, berührt von jedem replace_* / drop_*) und bei jedem Per-Pass-Reset geleert.
Die Zahlen, direkt aus der PR-Beschreibung:
| Eingabe | vorher | nachher | Effekt |
|---|---|---|---|
a + a + … × 4 000 | 234 ms | 0,9 ms | Skalierung 4,07x → 2,09x (O(n²) → O(n)) |
a + a + … × 8 000 | 953 ms | 1,9 ms | ab hier linear |
a + a + … × 20 000 | 6 118 ms | 4,7 ms | ≈1300x schneller |
| antd.js (echter Code) | 78,1 ms | 65,4 ms | ≈16% schneller bei realer Eingabe |
Die Quintessenz ist, dass arithmetische Additionsketten in der minifizierten Ausgabe (die in generiertem numerischen Code und in großen Polyfills vorkommen) um drei Größenordnungen fallen. Reale Bundles fallen beim ersten Lauf um 16%, wobei die Gewinne sich bei größeren Eingaben verstärken.
Der Zyklus hat fünf weitere erwähnenswerte Performance-Eintragungen. semantic: Flatten hoisting_variables to avoid per-scope map allocation (Lawrence Lin) entfernt die Pro-Scope-Map-Allokation, die bei jedem Hoisting-Variablen-Update ausgelöst wurde. isolated-declarations: Pool scope maps to avoid per-scope alloc/rehash (Boshen) poolt die von oxc_isolated_declarations verwendeten Scope-Maps, sodass die Pro-Funktion-Allokation/Rehash verschwindet. minifier: Bail member-expr folding before the side-effect walk (Lawrence Lin) faltet die einfachen Fälle von a.b.c.d-Ketten vor dem Side-Effect-Walk. parser: Avoid span lookup for arrow expression body (camc314) entfernt einen Hashmap-Lookup pro Pfeilfunktionsausdruck. Auf der Formatter-Seite bietet formatter_core: Add printable-ASCII fast path to TextWidth (Lawrence Lin) der Zeilenbreitenberechnung des Formatters einen Schnellpfad, wenn der Text reines druckbares ASCII ist, was die überwiegende Mehrheit der formatierten Ausgabe abdeckt.
Es gibt auch einen Cluster von drei PRs, die die AST-Knoten-Allokation aus Box::new_in in eine direkte Arena-Allokation verschieben: parser: Allocate AST nodes in arena directly (overlookmotel), minifier: Allocate AST nodes in arena directly (overlookmotel) und isolated_declarations: Allocate AST nodes in arena directly (overlookmotel). Zusammen ersetzen sie die Box::new_in-Indirektion durch eine direkte Bump-Allocator-Schreibung und entfernen eine Heap-Allokation pro AST-Knoten im Parser, im Minifier und in der isolated-declarations-Pipeline.
Oxfmt v0.57 entfernt den Prettier-Fallback für CSS / LESS / SCSS / GraphQL
Die größte strukturelle Änderung in Oxfmt ist die Entfernung des Prettier-Fallbacks für die CSS- und GraphQL-Grammatiken. Vor v0.57 konnte Oxfmt CSS- / LESS- / SCSS- und GraphQL-Dateien formatieren, tat dies aber durch Delegation an ein mitgeliefertes Prettier für diese Grammatiken. v0.57 entfernt den Fallback und formatiert beide Grammatiken nativ in Rust.
Die CSS-Seite landet als oxc_formatter_css (leaysgur) und wird über den BREAKING-Eintrag Format parser:css,less,scss files + css-in-js by oxc_formatter_css (leaysgur) verdrahtet. Der Crate ist eine eigenständige Formatter-Implementierung, die die bestehenden CSS- / LESS- / SCSS-Parser nimmt, den AST durchläuft und eine Prettier-kompatible Ausgabe emittiert. Die Versionsnotizen heben css-in-js explizit als unterstützt hervor: Template-Literale im Stil von styled-components und Emotion, die Oxfmt bereits erkennt und an den CSS-Parser weiterleitet, werden jetzt von oxc_formatter_css formatiert statt vom Prettier-Shim.
Die GraphQL-Seite landet als oxc_formatter_graphql (leaysgur) und wird über den BREAKING-Eintrag Support draft syntax with removing prettier fallback (leaysgur) verdrahtet. Der Teil « draft syntax » ist der Teil, der wirklich neu ist: Die vorherige GraphQL-Implementierung von Oxfmt behandelte die stabile 2021-Spec; die neue behandelt die GraphQL-October-2021-Draft-Syntax und die Working-Draft-Syntax, die von Apollo Federation und Yoga verwendet wird. Dies ist ein echtes Feature, nicht nur eine Umbenennung: Der Prettier-Fallback konnte die Draft-Syntax auch nicht behandeln, also schließt das Upgrade auch eine echte Format-on-Save-Lücke für Nutzer auf der Apollo-Stack.
Zwei Prettier-Diff-Paritäts-PRs bringen die Ausgabe der neuen Formatter näher an die von Prettier: formatter_css: Improve major prettier diffs (leaysgur) und formatter_graphql: Improve major prettier diffs (leaysgur). Die Versionsnotizen markieren, dass reale Diffs in bestehenden Codebasen weiterhin erwartet werden (das typische Muster « erster Lauf ändert einige Zeilen, nachfolgende Läufe sind idempotent »), aber die Lücke ist viel kleiner als in v0.56.
Das Release fügt auch formatter_css: Handle frontmatter language (leaysgur) hinzu, das Markdown-Frontmatter in CSS-Dateien (zum Beispiel den ----Block oben im <style>-Block einer Vue-SFC, wenn sie Frontmatter-Metadaten hat) an den Frontmatter-Parser weiterleitet, statt es als CSS zu behandeln, sowie den oben erwähnten druckbaren-ASCII-Schnellpfad in TextWidth.
Das Gesamtbild ist, dass Oxfmt kein « JS- / TS-Formatter mit Prettier-Beifahrer für alles andere » mehr ist. Nach v0.57 bleiben die JS- / TS- / JSON- / JSONC-Pfade auf dem internen Formatter (was seit v0.54 der Fall ist), und CSS / LESS / SCSS / css-in-js und GraphQL stoßen dazu. Die verbleibenden Grammatiken, die Prettier behandelt (Markdown, YAML, HTML), liegen nicht im Geltungsbereich von Oxfmt; Oxfmt überlässt sie explizit Prettier und den Prettier-3.9-Rust-Parsern, die am 27. Juni gelandet sind.
Der Zyklus berührt auch den Migrationsbefehl: fix(oxfmt): update --migrate prettier (leaysgur) räumt den Befehl zur Konfigurationsmigration Prettier → Oxfmt auf, um die neuen internen CSS- / GraphQL-Formatter zu behandeln. Der Befehl bleibt der empfohlene Weg, um eine bestehende Prettier-Konfiguration in ein Oxfmt-Projekt zu bringen; das v0.57-Update fügt die neuen Grammatiken zur Konversionstabelle hinzu.
Oxlint v1.72 Features und die Performance-Flut
Das Oxlint-v1.72.0-Apps-Release liefert drei Features, achtzehn Fehlerbehebungen und dreiundzwanzig Performance-Eintragungen auf Basis von crates_v0.138.0. Das herausragende Feature ist linter/react: Implement suggestion for no-unknown-property (Mikhail Baev), das einen Quick Fix zur React-Regel no-unknown-property hinzufügt. Vor v1.72 meldete die Regel das Problem ohne Code-Aktion; Editoren markierten die Eigenschaft als unbekannt, aber der Entwickler musste sie manuell umbenennen. Nach v1.72 kann der Editor ein direktes Umbenennen zur nächsten bekannten Eigenschaft anbieten.
Das zweite Feature ist ast: Unify old and new AstBuilders (overlookmotel), dieselbe Vereinheitlichung, die das crates-v0.138.0-Release antreibt. Die Apps-Seite wechselt den Importpfad zum vereinheitlichten AstBuilder, auf dem die Regelarbeit in diesem Zyklus aufbaut.
Das dritte Feature ist linter: Add schema for eslint/no-restricted-import (Sysix). Das Schema ermöglicht es Nutzern, die paths- und patterns-Arrays von no-restricted-import über das Konfigurationsschema statt über rohem JSON auszudrücken, was eine langjährige Lücke im ESLint → Oxlint-Konfigurationsmigrationspfad schließt.
Achtzehn Fehlerbehebungen reichen von Eckfall-Falschpositiven bis zu Panik-Verhinderungs-Fixes. Hervorstechend ist linter/prefer-called-exactly-once-with: Avoid out-of-bounds slice panic at end of file (Jerry Zhao), das eine echte Panik schloss, die den Linter auf Testdateien zum Absturz bringen konnte, in denen die Assertion der letzte Ausdruck war. Weitere bemerkenswerte Fixes: linter/unicorn/custom-error-definition: Handle non-ascii class names (camc314), linter/eslint/no-negated-condition: Add autofix for negated conditions (Yagiz Nizipli), linter/eslint/prefer-destructuring: Skip AssignmentExpression autofixes (camc314) und linter/eslint/no-restricted-globals: Handle shadowed locals (camc314).
Dreiundzwanzig Performance-Eintragungen setzen die Bucketed-Dispatch-Geschichte von v1.71 fort. Die herausragenden Eintragungen: linter/jsx-a11y: Skip lowercasing non-aria attribute names (Lawrence Lin), das eine to_ascii_lowercase-Allokation pro JSX-Attribut entfernt; linter/typescript/no-unsafe-declaration-merging: Use keyed binding lookup (Marius Schulz), das eine lineare Suche durch dieselbe Keyed-Binding-Tabelle ersetzt, die der v1.71-Bucketed-Dispatch einführte; linter/eslint/no-unused-vars: Precompute exported bindings (camc314); linter/unicorn/prefer-number-properties: Speed up global checks (camc314); linter/eslint/no-script-url: Match javascript: prefix without allocating (Lawrence Lin); und linter: Skip traversal without this expressions (camc314), das eine Klasse von Regeln kurzschließt, wenn keine this-Ausdrücke in der Datei vorhanden sind. Zusammen mit der v1.71-Bucketed-Dispatch-Grundlage bringen die v1.72-Performance-Eintragungen Oxlint an den Punkt, an dem die Wandzeit der meisten Regeln von der Baumdurchquerung dominiert wird, nicht von der regelinternen Allokationsfluktuation.
Die Linter-Fehlerbehebungen umfassen auch linter/jsx-a11y/role-supports-aria-props: Ignore nullish prop values (Mikhail Baev) und linter/eslint/no-warning-comments: Avoid dropping generated regex patterns (camc314), die beide Falschpositiv-Lücken in realem JSX schließen. Die LSP-Seite erhält lsp: Normalize user config path to watch pattern (Sysix), das einen langjährigen LSP-Pfadauflösungs-Bug unter Windows behebt.
Das Vue-typeof-define-keys-Feature
PR #23605 von Alexander Lichter fügt transformer_plugins: Support typeof define keys hinzu. Die PR fügt Unterstützung für typeof-Schlüssel innerhalb des define-Makromusters hinzu, auf das sich das Vue-Compiler-Macros-Plugin stützt. Vue-Makros defineProps, defineEmits, defineModel, defineSlots und Co. akzeptieren eine Laufzeitform (defineProps<typeof import('./foo').bar>()), und die vorherige transformer_plugins-Implementierung erkannte diese Form nicht. Nach v0.138 erkennt der transformer_plugins-Crate typeof-Schlüssel als Unterpattern des Makrokörpers, sodass der resultierende TypeScript-Code seine Typimporte durch die Makroexpansion beibehält.
Das Muster wird von den Vue-Ökosystem-Makros geteilt, die auf defineProps aufbauen. defineI18nLocale und defineI18nRoute von vue-i18n, die Auto-Import-Makros von Nuxt (defineNuxtConfig, defineNuxtPlugin) und die Makromuster in den Setup-Stores von pinia akzeptieren alle eine typeof import(...)-Referenz im Makrokörper. Vor dieser PR scheiterte der Transformer entweder beim Matchen des Makros (der Fallback-Pfad generierte das Makro als No-Op-Aufruf) oder behandelte, schlimmer, das typeof-Token als Wert und brach das Tracking von Typimporten.
Die PR ist auch die erste Änderung auf Oxc-Seite des v0.138-Zyklus mit einem Vue-Ökosystem-Beitragenden. Alexander Lichter ist der Maintainer von vue-router und ein häufiger Beitragender zur Vue-Compiler-Macros-Konversation; die typeof-Unterstützung entschärft ein langjähriges Problem im vue-i18n-Ökosystem und ist das deutlichste Signal in diesem Zyklus, dass die transformer_plugins-Oberfläche sich darauf zubewegt, auf realen Vue-Codebasen ohne einen vorgeschalteten vue-tsc-Durchlauf nutzbar zu sein.
Was zu beobachten ist
Drei Signale für die nächsten zwei bis drei Wochen. Erstens, beobachten Sie die v0.138.1-Patch-Linie und alle Berichte über Abwärtskompatibilitätsprobleme bei der AstBuilder-Migration: Die Legacy-Methoden sind in diesem Zyklus als #[deprecated] markiert, aber nachgelagerte Crates, die benutzerdefinierte ASTs auf Oxc aufbauen, werden jetzt Warnungen und im nächsten Zyklus Brüche erhalten. Das PR-Cluster um #23877 ist die Stelle, die zu beobachten ist; wenn ein nachgelagerter Crate (rolldown, biome, Vites Rolldown-Port, parcel) ein Issue zur neuen AstBuilder-Form öffnet, ist ein v0.139-Zyklus mit einem expliziten Migrationsleitfaden zu erwarten. Zweitens, beobachten Sie, ob Oxfmt v0.58 eine graphql-oder-css-Kompat-Paritätseintragung liefert. Die Prettier-Diff-Paritäts-PRs (#23327, #23419) haben die Lücke wesentlich geschlossen, aber die Versionsnotizen markieren reale Diffs weiterhin als erwartet; eine v0.58-Eintragung, die die Diff-Anzahl auf einer repräsentativen CSS- / GraphQL-Codebasis auf Null bringt, würde bestätigen, dass die neuen Formatter produktionsreif für die Migration sind. Drittens, beobachten Sie, ob die value_type-Memoisierung in oxc_isolated_declarations oder oxc_transformer landet. Das Design der PR #23929 ist explizit: Der Cache ist über Hooks auf GlobalContext opt-in, und nur der Minifier liefert in diesem Zyklus einen echten Cache. Der nächste Zyklus ist der natürliche Ort, damit der Transformer und isolated-declarations opt-in; wenn sie es tun, erhalten Type-Stripping-Pipelines denselben Performance-Gewinn bei arithmetischen Ketten, den der Minifier gerade erhalten hat.
Die breitere Lektion ist die, die der Prettier-3.9-Artikel vor zwei Tagen gezogen hat: Die JavaScript-Toolchain wird auf dem Rust-Oxc-Stack neu aufgebaut, eine Grammatik nach der anderen, und der v0.138-Zyklus schließt zwei weitere Grammatiken (CSS / LESS / SCSS und GraphQL auf der Oxfmt-Seite) und beendet eine interne API-Migration (AstBuilder + GetAllocator auf der crates-Seite). Dasselbe Muster zeigt sich bei Clines SDK-Migration, bei Vites Vite+-Vereinheitlichung (das Banner auf der Oxc-Website) und bei der Bun + Anthropic-Integration. Die Form von 2026 im gesamten Oxc-Ökosystem ist eine Sequenz großer Architektur-Umschreibungen, die in Etappen ausgeliefert werden, wobei jeder Zyklus eine weitere Komponente als « fertig » markiert und den nächsten Zyklus befreit, sich auf die verbleibenden Lücken zu konzentrieren.
