---
title: "Oxlint v1.71 et Oxfmt v0.56 livrent les gains des crates v0.137, ajoutent 18 nouvelles règles de linter et domptent la traversée du cycle de vie React avec un refactor en itérateur streamed"
description: "Oxlint apps_v1.71.0 et oxfmt apps_v0.56.0, tous deux publiés le 2026-06-22, bouclent le cycle des crates v0.137 côté apps. Oxlint v1.71 reprend la nouvelle passe de minifier `treeshake pure typed arrays` (#23469), le correctif `prefer-query-selector` à sélecteur composé, 28 corrections de bugs de lint (en grande partie le travail de réécriture de fixer de Yunfei He), 13 entrées de performance ancrées sur un refactor de dispatch de règles en buckets (#23450, #23452, #23482-#23486, #23489, #23492), et le démarrage de Tokio uniquement pour le LSP dans oxlint (#23447). Oxfmt v0.56.0 livre 9 corrections de bugs (normalisation CRLF pour le texte supprimé par `// @ts-ignore` dans #23701 et #23702, le correctif de panique de chaîne de membres #23698, la préservation du `export default` avec cast de type #23697) et 3 entrées de performance de formatter qui suppriment les copies d'arena sur le texte bigint, littéral numérique et littéral de chaîne. v1.71 est la première release d'apps depuis v1.70.0 le 2026-06-15, et la dernière avant la release de crates v0.138 qui arrivera le lundi 2026-06-29."
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 et oxfmt v0.56.0, tous deux publiés le 2026-06-22, bouclent le cycle des crates v0.137 côté apps. Oxlint reprend la passe de minifier `treeshake pure typed arrays and Set/Map array literals` (#23469, Dunqing) que la [release des crates v0.137](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) avait livrée mais que la release d'apps n'avait pas eue, plus les nouvelles options amont de `no-restricted-globals` (#23663), `node/no-sync` (#23589), `unicorn/prefer-number-coercion` (#23497) et `vue/no-async-in-computed-properties` (#23493)."
  - "Le côté performance est dominé par un refactor de dispatch de règles en buckets (#23450, #23452, camc314) : le linter réutilise désormais les buckets de dispatch de règles et les bras de match de `RuleEnum` entre fichiers au lieu d'émettre un bras de match par branche de timing (#23499, Boshen), évite les allocations temporaires de `Vec` dans `typescript/no-unnecessary-parameter-property-assignment` (#23492) et `eslint/no-useless-switch-case` (#23489), emprunte le texte de suggestion de branche partagée dans `oxc/branches-sharing-code` (#23484), et saute les collections d'enfants de fragment JSX (#23486). La release corrige aussi le coût de démarrage à froid d'oxlint : `oxlint: Start Tokio only for LSP` (#23447) laisse le runtime asynchrone dormant sur le chemin CLI."
  - "Oxfmt v0.56.0 normalise le CRLF pour le texte supprimé à la fois dans le formatter JSON (#23702) et dans le formatter JS/TS (#23701), corrige la panique de chaîne de membres quand la queue fusionne avec un commentaire dans un build dev (#23698), et livre trois entrées de perf de formatter qui évitent les copies d'arena pour les littéraux bigint déjà en minuscules (#23534), le texte de littéral numérique emprunté (#23512) et le texte de littéral de chaîne emprunté (#23465). Les 28 corrections de bugs de lint sont en grande partie le travail de réécriture de fixer de Yunfei He ; la plus marquante est le correctif de panique `parseInt(_, spread)` dans trois règles d'un coup (#23623, #23624, #23626)."
faq:
  - question: "Quel est le changement phare d'oxlint v1.71.0 ?"
    answer: "Le changement phare est le refactor de dispatch de règles en buckets (#23450, #23452, camc314) : le linter réutilise désormais les buckets de dispatch de règles et les bras de match de `RuleEnum` entre fichiers au lieu d'émettre un bras de match par branche de timing (#23499, Boshen). Sur un vrai monorepo avec plusieurs milliers de fichiers, le refactor supprime le coût de configuration par fichier qui dominait le temps mural d'oxlint sur les runs à froid ; le travail de règle lui-même était déjà rapide. Le chemin de démarrage à froid reçoit aussi le correctif `oxlint: Start Tokio only for LSP` (#23447), donc le CLI ne paie plus le coût de démarrage de Tokio quand il n'en a pas besoin."
  - question: "Est-ce qu'oxlint v1.71 livre les nouvelles passes de treeshaking du minifier des crates v0.137 ?"
    answer: "Oui. `treeshake pure typed arrays and Set/Map array literals` (#23469, Dunqing) arrive dans oxlint v1.71.0 ; c'est la reprise côté apps de la même PR que la [release des crates v0.137](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) avait livrée quatre jours plus tôt. La passe complémentaire `inline const value for read-only vars` (#22593) est aussi dans le build du minifier de v1.71. Les deux passes restent désactivées par défaut ; les défauts de `CompressOptions` du minifier correspondent à v0.136 / v1.70, donc les gains sont opt-in via la config."
  - question: "Quelles sont les nouvelles règles de linter les plus importantes ?"
    answer: "Trois règles se retrouvent en haut de la liste des plus importantes : `unicorn/prefer-number-coercion` (#23497, Shekhu), qui détecte au moment du lint le problème de cohérence entre `Number(x)`, `+x` et `parseFloat(x)` ; `node/no-sync` (#23589, fujitani sora), qui signale les appels synchrones au système de fichiers et aux processus enfants dans les points d'entrée serveur ; et `vue/no-async-in-computed-properties` (#23493, bab), qui comble un vrai trou de correction dans les définitions de computed properties Vue. Le schéma `eslint/no-restricted-properties` (#23619) et le support des options `unicorn/numeric-separators-style` (#23524, #23554) sont aussi notables parce qu'ils ouvrent des chemins de migration depuis des configs ESLint qui étaient auparavant manuels."
  - question: "Que fait le changement oxlint Tokio-uniquement-pour-LSP ?"
    answer: "`oxlint: Start Tokio only for LSP` (#23447, camc314) déplace le démarrage du runtime asynchrone Tokio hors du chemin CLI et dans le chemin LSP. Avant v1.71, oxlint démarrait un runtime Tokio à chaque invocation, même quand le CLI tournait de façon synchrone et n'en avait jamais besoin. Après v1.71, le chemin LSP reçoit toujours un runtime (il en a besoin pour piloter le protocole de language server), et le chemin CLI saute entièrement le coût de démarrage. Le correctif est petit sur les runs chauds mais visible sur les runs à froid en CI, où le démarrage de Tokio économisé se compose avec le refactor de dispatch en buckets pour donner au CLI de v1.71 une amélioration mesurable du temps mural sur les gros codebases."
  - question: "Qu'est-ce que le refactor du cycle de vie React dans v1.71 ?"
    answer: "`linter: Stream React lifecycle ancestors` (#23545, camc314) remplace la traversée précédente de `react/no-deprecated` et `react/jsx-no-undef`, qui collectait chaque ancêtre de chaque élément JSX dans un `Vec`, par un itérateur en streaming qui parcourt la chaîne d'ancêtres à la demande. Le refactor est la plus grande source de churn d'allocations sur les codebases React avec des composants profondément imbriqués. Combiné à `Avoid JSX fragment child collections` (#23486) et `Borrow shared branch suggestion text` dans `oxc/branches-sharing-code` (#23484), v1.71 est la première release où les règles de linter liées à React sont allocation-aware sur le chemin chaud."
  - question: "Y a-t-il des changements cassants dans oxlint v1.71 ?"
    answer: "Pas de suppression de règle cassante. La release resserre quelques comportements de fixer : `linter/curly: Remove only the block's own braces` (#23580) empêche la règle `curly` de supprimer les accolades qui appartiennent à un bloc parent quand le bloc interne n'en a pas, `linter/no-compare-neg-zero: Delete the - of a parenthesized -0` (#23578) préserve les parenthèses autour des comparaisons à `-0`, et `linter/array-type: Parenthesize a conditional-type element` (#23579) est un correctif de parité côté formatter. Aucun de ces changements ne modifie les défauts de règle, mais ils peuvent affecter la sortie du fixer sur des codebases qui s'appuyaient auparavant sur l'ancien comportement (incorrect)."
  - question: "Qu'est-ce qui change dans oxfmt v0.56.0 ?"
    answer: "Trois changements de fond. Premièrement, la normalisation CRLF pour le texte supprimé : `formatter_json: Normalize CRLF for suppressed text` (#23702) et `formatter: Normalize CRLF for suppressed text` (#23701) garantissent que les commentaires de suppression comme `// @ts-ignore` et `// oxlint-disable-next-line` conservent leurs fins de ligne quand le formatter réécrit le code environnant sur un projet qui mélange CRLF et LF. Deuxièmement, le correctif `formatter: Member chain panic when tail is merged with comment in dev build` (#23698) ferme une vraie panique dans le build dev qui se déclenchait quand la queue d'une chaîne de membres fusionnait avec un commentaire de fin. Troisièmement, `formatter: Preserve parens with default export and type cast` (#23697) conserve les parenthèses autour des constructions `export default x as Y` que le formatter aplatissait auparavant."
  - question: "Pourquoi le correctif de panique `parseInt(_, spread)` mérite d'être signalé ?"
    answer: "Le correctif est `linter/radix: Avoid panic on parseInt with a spread radix argument` (#23623, Jerry Zhao), et le même correctif a été appliqué à deux règles voisines dans la même release : `linter/prefer-numeric-literals` (#23624) et le suivi `linter/radix` (#23626). Le linter d'avant v1.71 paniquait sur `parseInt(x, ...args)` parce que le type runtime de l'argument radix n'était pas connu et que la règle supposait un littéral. Le correctif reconnaît le spread, diffère la vérification de radix, et rapporte la règle sans paniquer. Le correctif compte parce que les paniques dans un linter sont des échecs bruyants ; le comportement précédent faisait crasher la CI sur les codebases qui utilisaient `parseInt` avec des arguments radix calculés."
---

[Oxlint v1.71.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.71.0) et [oxfmt v0.56.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.71.0) sont sortis ensemble le 22 juin 2026, quatre jours après la [release crates_v0.137.0](/articles/2026-06-22--oxc-v0-137-react-compiler-treeshake-perf) et une semaine après la [release d'apps v1.70.0](/articles/2026-06-12--oxc-v0-135-react-compiler-ast-breaking). La release est la reprise côté apps du cycle des crates v0.137 et la dernière release d'apps avant que la ligne de crates v0.138 n'arrive le lundi 2026-06-29. Le travail phare est le refactor de dispatch de règles en buckets côté linter et la normalisation CRLF + le correctif de panique de chaîne de membres côté formatter.

La release Oxlint comporte 18 nouvelles fonctionnalités, 28 corrections de bugs et 13 entrées de performance. La release Oxfmt comporte 9 corrections de bugs et 3 entrées de performance. Au total : 71 entrées réparties sur les deux apps, dans la moyenne du cycle v1.70 et un peu au-dessus du cycle v1.68.

## Le titre : dispatch de règles en buckets

Le changement de performance le plus important de v1.71 est `linter: Reuse rule dispatch buckets` ([#23450](https://github.com/oxc-project/oxc/pull/23450), camc314), suivi de `linter: Use bucketed dispatch for all files` ([#23452](https://github.com/oxc-project/oxc/pull/23452), camc314). Avant v1.71, le linter émettait un bras de match de `RuleEnum` par branche de timing à chaque entrée dans une règle, puis réémettait les mêmes bras de match à chaque fichier suivant. Le refactor en buckets déplace les bras de match dans une seule allocation réutilisée entre tous les fichiers d'un run.

L'entrée de performance complémentaire est `linter: Emit RuleEnum dispatch match once instead of per timing branch` ([#23499](https://github.com/oxc-project/oxc/pull/23499), Boshen). Ensemble, les deux PR suppriment le coût de configuration par fichier qui dominait le temps mural d'oxlint sur les runs à froid. Le travail de règle lui-même était déjà rapide ; ce qui était coûteux, c'était la comptabilité autour.

La release corrige aussi le coût de démarrage à froid : `oxlint: Start Tokio only for LSP` ([#23447](https://github.com/oxc-project/oxc/pull/23447), camc314) déplace le démarrage du runtime asynchrone Tokio hors du chemin CLI. Avant v1.71, oxlint démarrait un runtime Tokio à chaque invocation, même quand le CLI tournait de façon synchrone et n'en avait jamais besoin. Après v1.71, le chemin LSP reçoit toujours un runtime (il en a besoin pour piloter le protocole de language server), et le chemin CLI saute entièrement le coût de démarrage.

## La reprise des crates v0.137

La release des crates v0.137 du 18 juin a livré deux nouvelles passes de treeshaking pour le minifier, un rafraîchissement de portée incrémental de longue haleine qui a supprimé `LiveUsageCollector`, et deux changements cassants d'ESTree. La release d'apps v1.71 reprend les parties visibles par l'utilisateur : `minifier: Treeshake pure typed arrays and Set/Map array literals` ([#23469](https://github.com/oxc-project/oxc/pull/23469), Dunqing) est dans le build du minifier de v1.71, avec la suppression de `LiveUsageCollector`, les correctifs de perf de l'analyseur et les entrées de perf du React Compiler. Les deux changements cassants d'ESTree (`#23574`, `#23573`) sont opt-in : ils concernent les crates en aval qui construisent un AST ESTree personnalisé, pas les utilisateurs d'oxlint.

La passe complémentaire de minifier `inline const value for read-only vars` ([#22593](https://github.com/oxc-project/oxc/pull/22593)) est aussi dans le build du minifier de v1.71. Les deux passes restent désactivées par défaut ; les défauts de `CompressOptions` du minifier dans v1.71 correspondent à v1.70 / v0.136, donc les gains sont opt-in via la config.

## 18 nouvelles règles de linter

La release v1.71 livre 18 nouvelles règles de linter réparties sur les catégories ESLint, TypeScript, Node, Unicorn, Vue, JSDoc et React. Les plus importantes :

- `unicorn/prefer-number-coercion` ([#23497](https://github.com/oxc-project/oxc/pull/23497), Shekhu) détecte au moment du lint le problème de cohérence entre `Number(x)`, `+x` et `parseFloat(x)`.
- `node/no-sync` ([#23589](https://github.com/oxc-project/oxc/pull/23589), fujitani sora) signale les appels synchrones au système de fichiers et aux processus enfants dans les points d'entrée serveur.
- `vue/no-async-in-computed-properties` ([#23493](https://github.com/oxc-project/oxc/pull/23493), bab) comble un vrai trou de correction dans les définitions de computed properties Vue.
- `node/no-mixed-requires` ([#23539](https://github.com/oxc-project/oxc/pull/23539), fujitani sora) signale les styles de require mélangés dans les modules CommonJS.
- `unicorn/max-nested-calls` ([#23461](https://github.com/oxc-project/oxc/pull/23461), arieleli01212) détecte les chaînes de fonctions trop imbriquées.

La release livre aussi le support de schéma pour `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), et `react/jsx-no-script-url` ([#23475](https://github.com/oxc-project/oxc/pull/23475), WaterWhisperer). Le travail de schéma ouvre des chemins de migration depuis des configs ESLint qui étaient auparavant manuels.

Côté suggestion, `linter/typescript: Implement suggestion for no-unnecessary-type-constraint rule` ([#23646](https://github.com/oxc-project/oxc/pull/23646), Mikhail Baev) et `linter/jsdoc/require-param-type: Implement fixer` ([#23513](https://github.com/oxc-project/oxc/pull/23513), camc314) ajoutent le support de l'auto-fix pour deux règles qui auparavant ne faisaient que rapporter.

## Le refactor du cycle de vie React

La plus grande source de churn d'allocations sur les codebases React avec des composants profondément imbriqués était la traversée de `react/no-deprecated` et `react/jsx-no-undef`, qui collectait chaque ancêtre de chaque élément JSX dans un `Vec` avant de faire le moindre travail de règle. `linter: Stream React lifecycle ancestors` ([#23545](https://github.com/oxc-project/oxc/pull/23545), camc314) remplace la collecte en `Vec` par un itérateur en streaming qui parcourt la chaîne d'ancêtres à la demande.

Combiné à `linter: Avoid JSX fragment child collections` ([#23486](https://github.com/oxc-project/oxc/pull/23486), camc314) et `linter/oxc/branches-sharing-code: Borrow shared branch suggestion text` ([#23484](https://github.com/oxc-project/oxc/pull/23484), camc314), v1.71 est la première release où les règles de linter liées à React sont allocation-aware sur le chemin chaud. Les trois PR représentent l'essentiel du travail de performance lié à React dans la release.

## 28 corrections de bugs de lint, en grande partie Yunfei He

Les 28 corrections de bugs de lint dans v1.71 sont dominées par le travail de réécriture de fixer de Yunfei He. Le pattern est le même d'un correctif à l'autre : le linter d'avant v1.71 réécrivait une construction de code en utilisant de la concaténation de chaînes, supprimait des parenthèses que la source avait explicitement ajoutées, ou collait un fragment dans une position qui produisait de la syntaxe invalide. Les correctifs de v1.71 préservent les parenthèses (`#23578`, `#23579`), préservent le texte source des opérandes (`#23533`), sautent les fixes sur des récepteurs qui ne sont pas du type attendu (`#23518`, `#23520`, `#23527`), et préservent les alias d'import (`#23568`).

Le correctif le plus marquant est la panique `parseInt(_, spread)`. `linter/radix: Avoid panic on parseInt with a spread radix argument` ([#23623](https://github.com/oxc-project/oxc/pull/23623), Jerry Zhao) ferme une vraie panique qui se déclenchait quand `parseInt(x, ...args)` était appelé avec un argument radix calculé. Le même correctif a été appliqué à deux règles voisines dans la même release : `linter/prefer-numeric-literals` ([#23624](https://github.com/oxc-project/oxc/pull/23624), Jerry Zhao) et le suivi `linter/radix` (#23626). Avant v1.71, le linter paniquait et faisait crasher la CI sur les codebases qui utilisaient `parseInt` avec des arguments radix calculés.

Autres corrections notables : `linter/prefer-query-selector: Use a compound selector for multiple classes` ([#23628](https://github.com/oxc-project/oxc/pull/23628), Jerry Zhao) corrige un trou de correction dans `prefer-query-selector` où un sélecteur multi-classes était réécrit comme une suite de sélecteurs mono-classe, cassant l'intention sémantique ; `linter: False positives with non *.setTimeout call in no-confusing-set-timeout` ([#23444](https://github.com/oxc-project/oxc/pull/23444), camc314) empêche la règle de signaler des appels à `setTimeout` venus d'un import renommé ; et `linter/eslint/no-useless-assignment: Handle exceptional control-flow paths` ([#23544](https://github.com/oxc-project/oxc/pull/23544), camc314) ferme un trou de correction où la règle ratait des assignations à l'intérieur de blocs `try`/`finally`.

## Les changements de formatter

Oxfmt v0.56.0 livre trois changements de fond. Le premier est la normalisation CRLF pour le texte supprimé : `formatter_json: Normalize CRLF for suppressed text` ([#23702](https://github.com/oxc-project/oxc/pull/23702), leaysgur) et `formatter: Normalize CRLF for suppressed text` ([#23701](https://github.com/oxc-project/oxc/pull/23701), leaysgur) garantissent que les commentaires de suppression comme `// @ts-ignore` et `// oxlint-disable-next-line` conservent leurs fins de ligne quand le formatter réécrit le code environnant sur un projet qui mélange CRLF et LF. Le deuxième est le correctif de panique de chaîne de membres : `formatter: Member chain panic when tail is merged with comment in dev build` ([#23698](https://github.com/oxc-project/oxc/pull/23698), leaysgur) ferme une panique dans le build dev qui se déclenchait quand la queue d'une chaîne de membres fusionnait avec un commentaire de fin. Le troisième est `formatter: Preserve parens with default export and type cast` ([#23697](https://github.com/oxc-project/oxc/pull/23697), leaysgur), qui conserve les parenthèses autour des constructions `export default x as Y` que le formatter aplatissait auparavant.

Les entrées de perf du formatter sont plus petites mais cohérentes : `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), et `formatter: Avoid arena copy for borrowed string-literal text` ([#23465](https://github.com/oxc-project/oxc/pull/23465), Yunfei He) suppriment tous des copies d'arena que le formatter d'avant v0.56 effectuait sur du texte dont le formatter avait déjà déterminé qu'il pouvait être emprunté sans risque.

## Ce que v1.71 ne change pas

La release ne change pas les défauts de règles, la surface de l'analyseur ni l'API publique du React Compiler. Les défauts de `CompressOptions` du minifier correspondent à v1.70 / v0.136. Le serveur LSP gagne le correctif de démarrage de Tokio mais ne gagne pas de nouvelle fonctionnalité de protocole. La prochaine release de crates le lundi 2026-06-29 (v0.138) sera la première à livrer des changements qui ne sont pas dans le cycle v0.137 ; la release d'apps v1.71 boucle le cycle qui a commencé avec crates_v0.135 le 2026-06-08 et qui passe par la release d'apps v1.70 le 2026-06-15.

La release est aussi la troisième à porter le format à sections à emoji (`🚀 Features`, `🐛 Bug Fixes`, `⚡ Performance`, `📚 Documentation`) de l'équipe Oxc, qu'[Oxc v0.135](/articles/2026-06-12--oxc-v0-135-react-compiler-ast-breaking) a introduit. Le pattern correspond au [format de changelog Biome](https://github.com/biomejs/biome/releases) et aux [notes de release de Vite 8](/articles/2026-04-08--vite-8-stable-seven-patches-in-three-weeks), et facilite le survol d'une release pour trouver ce qui compte pour votre code.

## À surveiller

Trois suites sont probables dans les deux à quatre prochaines semaines. La première est la release `crates_v0.138.0` le lundi 2026-06-29, qui sera la première release de crates hors du cycle v0.137. La deuxième est la release d'apps correspondante `oxlint v1.72.0` et `oxfmt v0.57.0` le lundi 2026-07-06, qui reprendra ce que la ligne de crates v0.138 livrera. La troisième est la continuation du refactor de dispatch en buckets de camc314 : la release v1.71 a posé les fondations, mais plusieurs règles utilisent encore le pattern d'allocation par règle que v1.71 a retiré pour la couche de dispatch ; il faut s'attendre à plus de travail de bucketing dans v1.72.