--- title: "Oxlint v1.71 und Oxfmt v0.56 liefern die v0.137-Crates-Gewinne aus, bringen 18 neue Linter-Regeln und zähmen die React-Lifecycle-Traversierung mit einem Streamed-Iterator-Refactor" description: "Oxlint apps_v1.71.0 und oxfmt apps_v0.56.0, beide am 2026-06-22 veröffentlicht, schließen den v0.137-Crates-Zyklus auf der Apps-Seite ab. Oxlint v1.71 übernimmt die neue `treeshake pure typed arrays`-Minifier-Passe (#23469), den `prefer-query-selector`-Compound-Selector-Fix, 28 Lint-Bugfixes (größtenteils Yunfei He Fixer-Rewrite-Arbeit), 13 Performance-Einträge, die auf einem Bucketed-Rule-Dispatch-Refactor aufsetzen (#23450, #23452, #23482-#23486, #23489, #23492), sowie den Tokio-nur-für-LSP-Start in oxlint (#23447). Oxfmt v0.56.0 liefert 9 Bugfixes (CRLF-Normalisierung für per `// @ts-ignore` unterdrückten Text in #23701 und #23702, den Member-Chain-Panic-Fix #23698, die Erhaltung von `export default` mit Type-Cast #23697) und 3 Formatter-Performance-Einträge, die Arena-Kopien auf BigInt-, Numeric-Literal- und String-Literal-Text vermeiden. v1.71 ist die erste Apps-Release seit v1.70.0 am 2026-06-15 und die letzte vor der v0.138-Crates-Release, die am Montag 2026-06-29 erscheinen wird." date: 2026-06-23 image: "/images/heroes/2026-06-23--oxlint-v1-71-oxfmt-v0-56.png" author: lschvn tags: ["tooling", "performance"] tldr: - "Oxlint v1.71.0 und oxfmt v0.56.0, beide am 2026-06-22 veröffentlicht, schließen den v0.137-Crates-Zyklus auf der Apps-Seite ab. Oxlint übernimmt die `treeshake pure typed arrays and Set/Map array literals`-Minifier-Passe (#23469, Dunqing), die die [v0.137-Crates-Release](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) geliefert hatte, die Apps-Release aber nicht, plus die neuen Upstream-Optionen für `no-restricted-globals` (#23663), `node/no-sync` (#23589), `unicorn/prefer-number-coercion` (#23497) und `vue/no-async-in-computed-properties` (#23493)." - "Die Performance-Seite wird von einem Bucketed-Rule-Dispatch-Refactor dominiert (#23450, #23452, camc314): Der Linter verwendet jetzt Rule-Dispatch-Buckets und `RuleEnum`-Match-Arme über Dateien hinweg wieder, statt einen Match-Arm pro Timing-Branch zu emittieren (#23499, Boshen), vermeidet temporäre `Vec`-Allokationen in `typescript/no-unnecessary-parameter-property-assignment` (#23492) und `eslint/no-useless-switch-case` (#23489), borgt sich geteilten Branch-Suggestion-Text in `oxc/branches-sharing-code` (#23484) und überspringt JSX-Fragment-Child-Collections (#23486). Die Release fixt zudem die Kaltstart-Kosten von oxlint: `oxlint: Start Tokio only for LSP` (#23447) lässt die Async-Runtime auf dem CLI-Pfad schlafen." - "Oxfmt v0.56.0 normalisiert CRLF für unterdrückten Text sowohl im JSON-Formatter (#23702) als auch im JS/TS-Formatter (#23701), fixt den Member-Chain-Panic, wenn das Ende mit einem Kommentar im Dev-Build verschmilzt (#23698), und liefert drei Formatter-Perf-Einträge, die Arena-Kopien für bereits kleingeschriebene BigInt-Literale (#23534), geborgten Numeric-Literal-Text (#23512) und geborgten String-Literal-Text (#23465) vermeiden. Die 28 Lint-Bugfixes sind größtenteils Yunfei He Fixer-Rewrite-Arbeit; am bemerkenswertesten ist der `parseInt(_, spread)`-Panic-Fix in gleich drei Regeln (#23623, #23624, #23626)." faq: - question: "Was ist die zentrale Änderung in oxlint v1.71.0?" answer: "Die zentrale Änderung ist der Bucketed-Rule-Dispatch-Refactor (#23450, #23452, camc314): Der Linter verwendet jetzt Rule-Dispatch-Buckets und `RuleEnum`-Match-Arme über Dateien hinweg wieder, statt einen Match-Arm pro Timing-Branch zu emittieren (#23499, Boshen). Auf einem realen Monorepo mit mehreren Tausend Dateien entfernt der Refactor die pro-Datei-Setup-Kosten, die bei Cold Runs die Wandzeit von oxlint dominierten; die eigentliche Regel-Arbeit war bereits schnell. Der Kaltstart-Pfad bekommt zusätzlich den `oxlint: Start Tokio only for LSP`-Fix (#23447), sodass die CLI die Tokio-Startup-Kosten nicht mehr zahlt, wenn sie sie nicht braucht." - question: "Liefert oxlint v1.71 die neuen Minifier-Treeshaking-Passes aus den v0.137-Crates aus?" answer: "Ja. `treeshake pure typed arrays and Set/Map array literals` (#23469, Dunqing) landet in oxlint v1.71.0; es ist die Apps-seitige Übernahme derselben PR, die die [v0.137-Crates-Release](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) vier Tage zuvor ausgeliefert hatte. Die Begleitpasse `inline const value for read-only vars` (#22593) ist ebenfalls im v1.71-Minifier-Build. Beide Passes bleiben standardmäßig aus; die `CompressOptions`-Defaults des Minifiers entsprechen v0.136 / v1.70, daher sind die Gewinne opt-in über die Konfiguration." - question: "Welche neuen Linter-Regeln sind am folgenreichsten?" answer: "Drei Regeln stehen ganz oben auf der Liste: `unicorn/prefer-number-coercion` (#23497, Shekhu), die das Konsistenzproblem zwischen `Number(x)`, `+x` und `parseFloat(x)` zur Lint-Zeit erkennt; `node/no-sync` (#23589, fujitani sora), die synchrone Dateisystem- und Kindprozess-Aufrufe in Server-Einstiegspunkten markiert; und `vue/no-async-in-computed-properties` (#23493, bab), die eine echte Korrektheitslücke in Vue-Computed-Property-Definitionen schließt. Die Schemas für `eslint/no-restricted-properties` (#23619) und der `unicorn/numeric-separators-style`-Options-Support (#23524, #23554) sind ebenfalls erwähnenswert, weil sie Migrationspfade aus ESLint-Konfigurationen eröffnen, die zuvor manuell waren." - question: "Was bewirkt die oxlint-Tokio-nur-für-LSP-Änderung?" answer: "`oxlint: Start Tokio only for LSP` (#23447, camc314) verschiebt den Tokio-Async-Runtime-Start aus dem CLI-Pfad in den LSP-Pfad. Vor v1.71 startete oxlint bei jeder Aufrufung eine Tokio-Runtime, auch wenn die CLI synchron lief und nie eine brauchte. Nach v1.71 bekommt der LSP-Pfad weiterhin eine Runtime (er braucht eine, um das Language-Server-Protokoll zu bedienen), und der CLI-Pfad überspringt die Startup-Kosten vollständig. Der Fix ist bei warmen Runs klein, aber bei kalten Runs in CI sichtbar, wo sich die ersparte Tokio-Startup-Zeit mit dem Bucketed-Dispatch-Refactor zu einer messbaren Wandzeit-Verbesserung der v1.71-CLI auf großen Codebases summiert." - question: "Was ist der React-Lifecycle-Refactor in v1.71?" answer: "`linter: Stream React lifecycle ancestors` (#23545, camc314) ersetzt die vorherige `react/no-deprecated`- und `react/jsx-no-undef`-Traversierung, die jeden Vorfahren jedes JSX-Elements in einem `Vec` sammelte, durch einen Streaming-Iterator, der die Vorfahrenkette bedarfsgesteuert durchläuft. Der Refactor ist die größte einzelne Quelle für Allokations-Churn auf React-Codebases mit tief verschachtelten Komponenten. Zusammen mit `Avoid JSX fragment child collections` (#23486) und `Borrow shared branch suggestion text` in `oxc/branches-sharing-code` (#23484) ist v1.71 die erste Release, in der die React-bezogenen Linter-Regeln auf dem Hot Path allokationsbewusst arbeiten." - question: "Gibt es Breaking Changes in oxlint v1.71?" answer: "Keine brechenden Regel-Entfernungen. Die Release zieht einige Fixer-Verhalten strammer: `linter/curly: Remove only the block's own braces` (#23580) hindert die `curly`-Regel daran, geschweifte Klammern zu entfernen, die zu einem Eltern-Block gehören, wenn der innere Block keine hat, `linter/no-compare-neg-zero: Delete the - of a parenthesized -0` (#23578) erhält Klammern um `-0`-Vergleiche, und `linter/array-type: Parenthesize a conditional-type element` (#23579) ist ein Paritäts-Fix auf der Formatter-Seite. Keine dieser Änderungen verändert Regel-Defaults, aber sie können die Fixer-Ausgabe auf Codebases beeinflussen, die sich zuvor auf das alte (fehlerhafte) Verhalten verließen." - question: "Was ändert sich in oxfmt v0.56.0?" answer: "Drei substanzielle Änderungen. Erstens, CRLF-Normalisierung für unterdrückten Text: `formatter_json: Normalize CRLF for suppressed text` (#23702) und `formatter: Normalize CRLF for suppressed text` (#23701) sorgen dafür, dass Unterdrückungskommentare wie `// @ts-ignore` und `// oxlint-disable-next-line` ihre Zeilenenden behalten, wenn der Formatter den umgebenden Code in einem Projekt umschreibt, das CRLF und LF mischt. Zweitens, der `formatter: Member chain panic when tail is merged with comment in dev build`-Fix (#23698) schließt einen echten Panic im Dev-Build, der ausgelöst wurde, wenn das Ende einer Member-Chain mit einem nachgestellten Kommentar verschmolz. Drittens, `formatter: Preserve parens with default export and type cast` (#23697) erhält Klammern um `export default x as Y`-Konstrukte, die der Formatter zuvor einebnete." - question: "Warum ist der `parseInt(_, spread)`-Panic-Fix erwähnenswert?" answer: "Der Fix ist `linter/radix: Avoid panic on parseInt with a spread radix argument` (#23623, Jerry Zhao), und derselbe Fix wurde in derselben Release auf zwei benachbarte Regeln angewendet: `linter/prefer-numeric-literals` (#23624) und der `linter/radix`-Follow-up (#23626). Der Linter vor v1.71 panicte bei `parseInt(x, ...args)`, weil der Runtime-Typ des Radix-Arguments nicht bekannt war und die Regel ein Literal annahm. Der Fix erkennt das Spread, verzögert die Radix-Prüfung und meldet die Regel ohne Panic. Der Fix ist wichtig, weil Panics in einem Linter laute Fehler sind; das vorherige Verhalten ließ die CI auf Codebases abstürzen, die `parseInt` mit berechneten Radix-Argumenten verwendeten." --- [Oxlint v1.71.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.71.0) und [oxfmt v0.56.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.71.0) sind am 22. Juni 2026 gemeinsam erschienen, vier Tage nach der [crates_v0.137.0-Release](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) und eine Woche nach der [v1.70.0-Apps-Release](/articles/2026-06-12--oxc-v0-135-react-compiler-ast-breaking). Die Release ist die Apps-seitige Übernahme des v0.137-Crates-Zyklus und die letzte Apps-Release, bevor die v0.138-Crates-Linie am Montag 2026-06-29 erscheint. Die zentrale Arbeit ist der Bucketed-Rule-Dispatch-Refactor auf der Linter-Seite und die CRLF-Normalisierung plus der Member-Chain-Panic-Fix auf der Formatter-Seite. Die Oxlint-Release trägt 18 neue Features, 28 Bugfixes und 13 Performance-Einträge. Die Oxfmt-Release trägt 9 Bugfixes und 3 Performance-Einträge. Insgesamt: 71 Einträge über die beiden Apps verteilt, vergleichbar mit dem v1.70-Zyklus und leicht über dem v1.68-Zyklus. ## Das zentrale Thema: Bucketed Rule Dispatch Die größte einzelne Performance-Änderung in v1.71 ist `linter: Reuse rule dispatch buckets` ([#23450](https://github.com/oxc-project/oxc/pull/23450), camc314), gefolgt von `linter: Use bucketed dispatch for all files` ([#23452](https://github.com/oxc-project/oxc/pull/23452), camc314). Vor v1.71 emittierte der Linter einen `RuleEnum`-Match-Arm pro Timing-Branch bei jedem Eintritt in eine Regel und emittierte dieselben Match-Arme bei jeder folgenden Datei erneut. Der Bucketed-Refactor verschiebt die Match-Arme in eine einzige Allokation, die über alle Dateien eines Runs hinweg wiederverwendet wird. Der ergänzende Performance-Eintrag ist `linter: Emit RuleEnum dispatch match once instead of per timing branch` ([#23499](https://github.com/oxc-project/oxc/pull/23499), Boshen). Zusammen entfernen die beiden PRs die pro-Datei-Setup-Kosten, die bei Cold Runs die Wandzeit von oxlint dominierten. Die Regel-Arbeit selbst war bereits schnell; teuer war die Buchhaltung darum herum. Die Release fixt zudem die Kaltstart-Kosten: `oxlint: Start Tokio only for LSP` ([#23447](https://github.com/oxc-project/oxc/pull/23447), camc314) verschiebt den Tokio-Async-Runtime-Start aus dem CLI-Pfad. Vor v1.71 startete oxlint bei jeder Aufrufung eine Tokio-Runtime, auch wenn die CLI synchron lief und nie eine brauchte. Nach v1.71 bekommt der LSP-Pfad weiterhin eine Runtime (er braucht eine, um das Language-Server-Protokoll zu bedienen), und der CLI-Pfad überspringt die Startup-Kosten vollständig. ## Die v0.137-Crates-Übernahme Die v0.137-Crates-Release vom 18. Juni lieferte zwei neue Minifier-Treeshaking-Passes, einen lang laufenden inkrementellen Scoping-Refresh, der `LiveUsageCollector` entfernte, und zwei ESTree-Breaking-Changes. Die v1.71-Apps-Release übernimmt die für den Benutzer sichtbaren Teile: `minifier: Treeshake pure typed arrays and Set/Map array literals` ([#23469](https://github.com/oxc-project/oxc/pull/23469), Dunqing) ist im v1.71-Minifier-Build, zusammen mit der `LiveUsageCollector`-Entfernung, den Parser-Performance-Patches und den React-Compiler-Performance-Einträgen. Die beiden ESTree-Breaking-Changes (`#23574`, `#23573`) sind opt-in: Sie betreffen nachgelagerte Crates, die einen eigenen ESTree-AST bauen, nicht die Oxlint-Nutzer. Die Begleit-Minifier-Passe `inline const value for read-only vars` ([#22593](https://github.com/oxc-project/oxc/pull/22593)) ist ebenfalls im v1.71-Minifier-Build. Beide Passes bleiben standardmäßig aus; die `CompressOptions`-Defaults des Minifiers entsprechen in v1.71 v1.70 / v0.136, daher sind die Gewinne opt-in über die Konfiguration. ## 18 neue Linter-Regeln Die v1.71-Release liefert 18 neue Linter-Regeln aus den Kategorien ESLint, TypeScript, Node, Unicorn, Vue, JSDoc und React. Die wichtigsten: - `unicorn/prefer-number-coercion` ([#23497](https://github.com/oxc-project/oxc/pull/23497), Shekhu) erkennt das Konsistenzproblem zwischen `Number(x)`, `+x` und `parseFloat(x)` zur Lint-Zeit. - `node/no-sync` ([#23589](https://github.com/oxc-project/oxc/pull/23589), fujitani sora) markiert synchrone Dateisystem- und Kindprozess-Aufrufe in Server-Einstiegspunkten. - `vue/no-async-in-computed-properties` ([#23493](https://github.com/oxc-project/oxc/pull/23493), bab) schließt eine echte Korrektheitslücke in Vue-Computed-Property-Definitionen. - `node/no-mixed-requires` ([#23539](https://github.com/oxc-project/oxc/pull/23539), fujitani sora) markiert gemischte Require-Stile in CommonJS-Modulen. - `unicorn/max-nested-calls` ([#23461](https://github.com/oxc-project/oxc/pull/23461), arieleli01212) erkennt zu tief verschachtelte Funktionsketten. Die Release liefert außerdem Schema-Support für `eslint/no-restricted-properties` ([#23619](https://github.com/oxc-project/oxc/pull/23619), Sysix), `node/callback-return` ([#23615](https://github.com/oxc-project/oxc/pull/23615), Sysix), `import/extensions` ([#23557](https://github.com/oxc-project/oxc/pull/23557), WaterWhisperer), `unicorn/numeric-separators-style` ([#23554](https://github.com/oxc-project/oxc/pull/23554), Mikhail Baev), `eslint/prefer-destructuring` ([#23410](https://github.com/oxc-project/oxc/pull/23410), WaterWhisperer) und `react/jsx-no-script-url` ([#23475](https://github.com/oxc-project/oxc/pull/23475), WaterWhisperer). Die Schema-Arbeit eröffnet Migrationspfade aus ESLint-Konfigurationen, die zuvor manuell waren. Auf der Suggestion-Seite fügen `linter/typescript: Implement suggestion for no-unnecessary-type-constraint rule` ([#23646](https://github.com/oxc-project/oxc/pull/23646), Mikhail Baev) und `linter/jsdoc/require-param-type: Implement fixer` ([#23513](https://github.com/oxc-project/oxc/pull/23513), camc314) Auto-Fix-Support für zwei Regeln hinzu, die zuvor nur meldeten. ## Der React-Lifecycle-Refactor Die größte einzelne Quelle für Allokations-Churn auf React-Codebases mit tief verschachtelten Komponenten war die `react/no-deprecated`- und `react/jsx-no-undef`-Traversierung, die jeden Vorfahren jedes JSX-Elements in einem `Vec` sammelte, bevor sie irgendwelche Regel-Arbeit verrichtete. `linter: Stream React lifecycle ancestors` ([#23545](https://github.com/oxc-project/oxc/pull/23545), camc314) ersetzt die `Vec`-Sammlung durch einen Streaming-Iterator, der die Vorfahrenkette bedarfsgesteuert durchläuft. Zusammen mit `linter: Avoid JSX fragment child collections` ([#23486](https://github.com/oxc-project/oxc/pull/23486), camc314) und `linter/oxc/branches-sharing-code: Borrow shared branch suggestion text` ([#23484](https://github.com/oxc-project/oxc/pull/23484), camc314) ist v1.71 die erste Release, in der die React-bezogenen Linter-Regeln auf dem Hot Path allokationsbewusst arbeiten. Die drei PRs machen zusammen den Großteil der React-bezogenen Performance-Arbeit in dieser Release aus. ## 28 Lint-Bugfixes, größtenteils Yunfei He Die 28 Lint-Bugfixes in v1.71 werden von Yunfei He Fixer-Rewrite-Arbeit dominiert. Das Muster ist über alle Fixes hinweg dasselbe: Der Linter vor v1.71 schrieb eine Code-Konstruktion mit String-Konkatenation um, entfernte Klammern, die der Quellcode explizit hinzugefügt hatte, oder klebte ein Fragment an eine Stelle, die ungültige Syntax erzeugte. Die v1.71-Fixes erhalten Klammern (`#23578`, `#23579`), erhalten den Operand-Quelltext (`#23533`), überspringen Fixes auf Empfängern, die nicht vom erwarteten Typ sind (`#23518`, `#23520`, `#23527`), und erhalten Import-Aliase (`#23568`). Der bemerkenswerteste Fix ist der `parseInt(_, spread)`-Panic. `linter/radix: Avoid panic on parseInt with a spread radix argument` ([#23623](https://github.com/oxc-project/oxc/pull/23623), Jerry Zhao) schließt einen echten Panic, der ausgelöst wurde, wenn `parseInt(x, ...args)` mit einem berechneten Radix-Argument aufgerufen wurde. Derselbe Fix wurde in derselben Release auf zwei benachbarte Regeln angewendet: `linter/prefer-numeric-literals` ([#23624](https://github.com/oxc-project/oxc/pull/23624), Jerry Zhao) und der `linter/radix`-Follow-up (#23626). Vor v1.71 panicte der Linter und ließ die CI auf Codebases abstürzen, die `parseInt` mit berechneten Radix-Argumenten verwendeten. Weitere erwähnenswerte Bugfixes: `linter/prefer-query-selector: Use a compound selector for multiple classes` ([#23628](https://github.com/oxc-project/oxc/pull/23628), Jerry Zhao) fixt eine Korrektheitslücke in `prefer-query-selector`, bei der ein Multi-Class-Selektor als Folge von Single-Class-Selektoren umgeschrieben wurde, was die semantische Absicht brach; `linter: False positives with non *.setTimeout call in no-confusing-set-timeout` ([#23444](https://github.com/oxc-project/oxc/pull/23444), camc314) hindert die Regel daran, `setTimeout`-Aufrufe aus einem umbenannten Import zu markieren; und `linter/eslint/no-useless-assignment: Handle exceptional control-flow paths` ([#23544](https://github.com/oxc-project/oxc/pull/23544), camc314) schließt eine Korrektheitslücke, bei der die Regel Zuweisungen innerhalb von `try`/`finally`-Blöcken übersah. ## Die Formatter-Änderungen Oxfmt v0.56.0 liefert drei substanzielle Änderungen. Die erste ist die CRLF-Normalisierung für unterdrückten Text: `formatter_json: Normalize CRLF for suppressed text` ([#23702](https://github.com/oxc-project/oxc/pull/23702), leaysgur) und `formatter: Normalize CRLF for suppressed text` ([#23701](https://github.com/oxc-project/oxc/pull/23701), leaysgur) sorgen dafür, dass Unterdrückungskommentare wie `// @ts-ignore` und `// oxlint-disable-next-line` ihre Zeilenenden behalten, wenn der Formatter den umgebenden Code in einem Projekt umschreibt, das CRLF und LF mischt. Die zweite ist der Member-Chain-Panic-Fix: `formatter: Member chain panic when tail is merged with comment in dev build` ([#23698](https://github.com/oxc-project/oxc/pull/23698), leaysgur) schließt einen Panic im Dev-Build, der ausgelöst wurde, wenn das Ende einer Member-Chain mit einem nachgestellten Kommentar verschmolz. Die dritte ist `formatter: Preserve parens with default export and type cast` ([#23697](https://github.com/oxc-project/oxc/pull/23697), leaysgur), die Klammern um `export default x as Y`-Konstrukte erhält, die der Formatter zuvor einebnete. Die Formatter-Performance-Einträge sind kleiner, aber konsistent: `formatter: Avoid arena copy for already-lowercase bigint literals` ([#23534](https://github.com/oxc-project/oxc/pull/23534), Yunfei He), `formatter: Avoid arena copy for borrowed numeric-literal text` ([#23512](https://github.com/oxc-project/oxc/pull/23512), Yunfei He) und `formatter: Avoid arena copy for borrowed string-literal text` ([#23465](https://github.com/oxc-project/oxc/pull/23465), Yunfei He) entfernen alle Arena-Kopien, die der Formatter vor v0.56 auf Text durchführte, von dem der Formatter bereits festgestellt hatte, dass er gefahrlos geborgt werden konnte. ## Was v1.71 nicht ändert Die Release ändert keine Regel-Defaults, die Parser-Oberfläche oder die öffentliche API des React Compilers. Die `CompressOptions`-Defaults des Minifiers entsprechen v1.70 / v0.136. Der LSP-Server erhält den Tokio-Startup-Fix, aber keine neue Protokollfunktion. Die nächste Crates-Release am Montag 2026-06-29 (v0.138) wird die erste sein, die Änderungen ausliefert, die nicht im v0.137-Zyklus sind; die v1.71-Apps-Release schließt den Zyklus ab, der mit crates_v0.135 am 2026-06-08 begann und über die v1.70-Apps-Release am 2026-06-15 läuft. Die Release ist zudem die dritte, die das Emoji-Section-Format (`🚀 Features`, `🐛 Bug Fixes`, `⚡ Performance`, `📚 Documentation`) des Oxc-Teams trägt, das [Oxc v0.135](/articles/2026-06-12--oxc-v0-135-react-compiler-ast-breaking) einführte. Das Muster entspricht dem [Biome-Changelog-Format](https://github.com/biomejs/biome/releases) und den [Vite-8-Release-Notes](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks) und macht es einfacher, eine Release danach zu scannen, was für Ihren Code relevant ist. ## Was zu beobachten ist Drei Nachfolgeereignisse sind in den nächsten zwei bis vier Wochen wahrscheinlich. Das erste ist die `crates_v0.138.0`-Release am Montag 2026-06-29, die erste Crates-Release außerhalb des v0.137-Zyklus. Das zweite ist die entsprechende `oxlint v1.72.0`- und `oxfmt v0.57.0`-Apps-Release am Montag 2026-07-06, die aufgreift, was die v0.138-Crates-Linie ausliefert. Das dritte ist die Fortsetzung von camc314s Bucketed-Dispatch-Refactor: Die v1.71-Release hat das Fundament gelegt, aber mehrere Regeln verwenden noch das pro-Regel-Allokationsmuster, das v1.71 für die Dispatch-Schicht abgeschafft hat; rechnen Sie mit weiterer Bucketing-Arbeit in v1.72.