--- title: "Oxlint v1.72 et Oxfmt v0.57 livrent le cycle crates v0.138, unifient l'AstBuilder et retirent le repli Prettier pour CSS/GraphQL" description: "Oxlint apps_v1.72.0 et oxfmt apps_v0.57.0, tous deux publiés le 2026-06-29, clôturent le cycle v0.138 prédit dans les [notes de version v1.71](/articles/2026-06-23--oxlint-v1-71-oxfmt-v0-56). La version crates (crates_v0.138.0, aussi 2026-06-29) unifie les anciennes et nouvelles API AstBuilder (#23876, #23834, #23831, avec les méthodes héritées marquées `#[deprecated]`), renomme `AllocatorAccessor` en `GetAllocator` et fait prendre `&self` à sa méthode `allocator` (#23675, #23676), fait prendre `&GetAllocator` aux méthodes `Str` et `Ident` (#23781), ajoute `transformer_plugins: Support typeof define keys` pour vue-i18n et macros similaires (#23605, Alexander Lichter), et livre l'entrée de perf phare du cycle : `minifier: memoize value_type to remove its O(n^2) re-walk on long binary chains` (#23929, Dunqing), qui transforme une chaîne d'addition arithmétique de 20 000 termes de 6 118 ms à 4,7 ms (≈1300x) et le bundle antd.js réel de 78,1 ms à 65,4 ms. Oxlint v1.72.0 livre 3 fonctionnalités (suggestion React pour `no-unknown-property` #23936, unification AstBuilder #23875, schéma pour `eslint/no-restricted-import` #23642), 18 corrections de bugs, et 23 entrées de performance. Oxfmt v0.57.0 comporte deux changements BREAKING qui retirent le repli Prettier pour les fichiers CSS/LESS/SCSS et GraphQL : `Format parser:css,less,scss files + css-in-js by oxc_formatter_css` (#23321, leaysgur) et `Support draft syntax with removing prettier fallback` (#23326, leaysgur), tous deux construits sur les nouveaux crates `oxc_formatter_css` (#23320) et `oxc_formatter_graphql` (#23317)." date: 2026-06-30 image: "/images/heroes/2026-06-30--oxlint-v1-72-oxfmt-v0-57-ast-builder-css-graphql-native.png" author: lschvn tags: ["tooling", "performance"] tldr: - "[Oxlint v1.72.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.72.0) et [oxfmt v0.57.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.72.0) sont sortis ensemble le 29 juin 2026, sur la base de [crates_v0.138.0](https://github.com/oxc-project/oxc/releases/tag/crates_v0.138.0). La version Oxc comporte six changements API BREAKING, tous dans les crates Rust `oxc_ast` / `oxc_allocator` / `oxc_ecmascript` : les anciennes et nouvelles `AstBuilder` sont unifiées derrière une seule exportation `AstBuilder` avec les méthodes héritées marquées `#[deprecated]` (#23876, #23834, #23831, #23877), `AllocatorAccessor` est renommé en `GetAllocator` (#23675), `GetAllocator::allocator` prend `&self` (#23676), et les méthodes `Str` / `Ident` prennent `&GetAllocator` (#23781). Ces changements cassent les crates en aval qui construisent des AST personnalisés sur Oxc mais n'affectent pas les utilisateurs d'oxlint / oxfmt." - "La plus grande entrée de perf visible par l'utilisateur du cycle est la [PR #23929](https://github.com/oxc-project/oxc/pull/23929) (Dunqing) : `perf(minifier): memoize value_type to remove its O(n^2) re-walk on long binary chains`. Le peephole post-order du minifier évaluait `Expression::value_type` à chaque nœud et parcourait à nouveau tout le sous-arbre gauche sur chaque chaîne binaire, donc un `a + a + … + a` de 20 000 termes prenait ~6 118 ms. La mémoïsation de `value_type` par adresse de nœud transforme la même entrée en 4,7 ms (≈1300x), la variante à 4 000 termes de 234 ms à 0,9 ms (passage à l'échelle 4,07x → 2,09x), et antd.js de 78,1 ms à 65,4 ms. Le cache vit sur `MinifierState` et est opt-in via des hooks sur `GlobalContext`, donc chaque appelant non-minifier conserve le comportement non mis en cache précédent." - "[Oxfmt v0.57.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.72.0) retire le repli Prettier pour les fichiers CSS / LESS / SCSS et GraphQL via deux changements BREAKING : `Format parser:css,less,scss files + css-in-js by oxc_formatter_css` (#23321, leaysgur) et `Support draft syntax with removing prettier fallback` (#23326, leaysgur), tous deux construits sur les nouveaux crates `oxc_formatter_css` (#23320) et `oxc_formatter_graphql` (#23317). Cela continue la même thématique que les [notes de version Prettier 3.9](/articles/2026-06-28--prettier-3-9-micromark-yaml-graphql-rust-flow-parser) du 28 juin, où Prettier adoptait les parseurs Oxc pour GraphQL, Markdown et Flow ; Oxfmt boucle maintenant la boucle en réécrivant CSS / SCSS / GraphQL sans quitter Rust." faq: - question: "Quelle est la principale nouveauté de la version crates Oxc v0.138 ?" answer: "Six changements cassants concentrés dans les crates Rust `oxc_ast` / `oxc_allocator` / `oxc_ecmascript`, tous faisant partie d'une seule histoire unificatrice : les anciennes et nouvelles `AstBuilder` fusionnent en une seule. La PR #23876 (overlookmotel) restreint le module `oxc_ast::builder` à exporter uniquement le type `AstBuilder` et le sentinelle `NONE` ; #23834 (overlookmotel) fait passer `oxc_ecmascript` à la nouvelle `AstBuilder` ; #23831 (overlookmotel) fait passer le transformer à la nouvelle `AstBuilder` ; #23875 (overlookmotel) supprime la duplication interne en unifiant les builders ; et #23877 marque les méthodes `AstBuilder` héritées comme `#[deprecated]`. Côté allocateur, `AllocatorAccessor` est renommé en `GetAllocator` (#23675) et `GetAllocator::allocator` passe à `&self` (#23676). Côté str, les méthodes `Str` et `Ident` prennent `&GetAllocator` (#23781). Les crates en aval qui construisent des AST personnalisés sur Oxc doivent mettre à jour leurs sites d'appel ; les utilisateurs d'oxlint et oxfmt ne voient aucun changement car les apps reposent déjà sur le builder unifié." - question: "Pourquoi l'unification AstBuilder est-elle importante ?" answer: "Avant v0.138, l'arbre Oxc livrait deux builders AST parallèles : un builder « hérité » conservé pour les appelants qui n'avaient pas migré, et le nouveau builder vers lequel les crates `oxc_ecmascript` et transformer avaient migré. Les deux builders dupliquaient la logique pour chaque type de nœud, doublaient la surface de maintenance pour le parseur, et forçaient chaque contributeur à choisir un camp. L'unification v0.138 achève la migration : il n'y a qu'un seul `AstBuilder`, les méthodes héritées sont marquées `#[deprecated]` (#23877), et les crates internes qui utilisaient encore le builder hérité (le transformer et `oxc_ecmascript`) basculent (#23831, #23834). Le crate `oxc_ast` reçoit aussi un flag de feature Cargo `disable_old_builder` pour les tests (#23888, #23886), donc les crates en aval qui doivent migrer peuvent activer le flag et voir ce qui casse. Le changement est invisible aux utilisateurs JS / TS d'oxlint et oxfmt ; il est très visible pour quiconque construit une couche AST personnalisée sur Oxc." - question: "À quelle vitesse la mémoïsation `value_type` est-elle ?" answer: "Les chiffres phares de la PR #23929 (Dunqing) : une chaîne d'addition arithmétique de 4 000 termes `a + a + … + a` passe de 234 ms à 0,9 ms (passage à l'échelle 4,07x → 2,09x, c'est-à-dire O(n²) → O(n)), une chaîne de 8 000 termes passe de 953 ms à 1,9 ms, une chaîne de 20 000 termes passe de 6 118 ms à 4,7 ms (≈1300x), et le bundle antd.js réel passe de 78,1 ms à 65,4 ms. Le cache est indexé par adresse de nœud et vit sur `MinifierState` ; il est invalidé au point unique de mutation (`record_mutation`, touché par chaque `replace_*` / `drop_*`) et à chaque reset par passe. Le cache est exposé comme hooks opt-in sur `GlobalContext` (`cached_value_type` / `cache_value_type`) ; seul le `TraverseCtx` du minifier fournit un vrai cache, donc chaque appelant non-minifier (évaluation de constantes, effets de bord, le harnais unitaire `value_type`, `WithoutGlobalReferenceInformation`) conserve le comportement non mis en cache exact précédent." - question: "Que change concrètement le retrait du repli Prettier d'Oxfmt v0.57 ?" answer: "Avant v0.57, oxfmt pouvait formater les fichiers CSS / LESS / SCSS et GraphQL, mais le faisait en déléguant à un Prettier groupé pour ces grammaires. v0.57 retire le repli Prettier et formate les deux grammaires nativement en Rust. Le côté CSS arrive sous le nom d'`oxc_formatter_css` (#23320, leaysgur) et est connecté via l'entrée BREAKING `Format parser:css,less,scss files + css-in-js by oxc_formatter_css` (#23321, leaysgur) ; le côté GraphQL arrive sous le nom d'`oxc_formatter_graphql` (#23317) et est connecté via l'entrée BREAKING `Support draft syntax with removing prettier fallback` (#23326, leaysgur). Les notes de version signalent le chemin css-in-js comme pris en charge par le nouveau formateur (c'est-à-dire que les template literals de style `styled-components` / Emotion sont maintenant formatés par Oxc, pas Prettier). Deux PR de parité avec Prettier (#23327 pour CSS, #23419 pour GraphQL) rapprochent la sortie de celle de Prettier, mais les projets s'attendent encore à des diffs réels sur les bases de code existantes. Combiné au correctif frontmatter CSS (#23819) et au fast path ASCII imprimable dans `TextWidth` (#23913), v0.57 est la version où oxfmt n'est plus un « formateur JS/TS avec un sidecar Prettier pour le reste »." - question: "Quelles nouvelles règles ou entrées de schéma Oxlint v1.72.0 ?" answer: "Trois nouvelles fonctionnalités et un schéma. Le changement phare côté règles est `linter/react: Implement suggestion for no-unknown-property` (#23936, Mikhail Baev), qui ajoute un Quick Fix à la règle React `no-unknown-property` pour que les éditeurs puissent renommer la propriété sur place ; avant v1.72 la règle signalait seulement le problème. Le changement d'infrastructure phare est `ast: Unify old and new AstBuilders` (#23875, overlookmotel), la même unification qui motorise la version crates v0.138. La troisième fonctionnalité est `linter: Add schema for eslint/no-restricted-import` (#23642, Sysix), qui permet aux utilisateurs d'exprimer les tableaux `paths` et `patterns` de `no-restricted-import` via le schéma de configuration plutôt qu'en JSON brut. Le reste de v1.72, ce sont 18 corrections de bugs (pour la plupart le travail de réécriture des fixers de Yunfei He ; le meilleur est le correctif `linter/prefer-called-exactly-once-with: Avoid out-of-bounds slice panic at end of file` #23625) et 23 entrées de performance, dont `linter/jsx-a11y: Skip lowercasing non-aria attribute names` (#23906, Lawrence Lin), `linter/typescript/no-unsafe-declaration-merging: Use keyed binding lookup` (#23894, Marius Schulz), `linter/eslint/no-unused-vars: Precompute exported bindings` (#23881, camc314), et le nouveau `linter: Skip traversal without this expressions` (#23845, camc314) qui court-circuite une classe de règles quand il n'y a aucune `this`-expression dans le fichier." - question: "Pourquoi la fonctionnalité typeof define keys est-elle importante pour Vue ?" answer: "La PR #23605 d'Alexander Lichter (mainteneur de vue-router et contributeur fréquent du compilateur Vue) ajoute le support des clés `typeof` à l'intérieur du pattern de macro `define` sur lequel le plugin compiler-macros de Vue s'aligne. Les macros Vue `defineProps`, `defineEmits`, et autres acceptent une forme runtime (`defineProps()`), et l'implémentation transformer_plugins précédente ne reconnaissait pas cette forme. Après v0.138, le crate `transformer_plugins` reconnaît les clés `typeof` comme sous-pattern du corps de macro, donc le code TypeScript résultant conserve ses imports de types à travers l'expansion de macro. La même mécanique est partagée par les macros de l'écosystème Vue qui reposent sur `defineProps`. `defineI18nLocale` et `defineI18nRoute` de vue-i18n, les macros d'auto-import de Nuxt (`defineNuxtConfig`, `defineNuxtPlugin`), et les patterns de macro des setup stores de pinia acceptent tous une référence `typeof import(...)` dans le corps de macro. Le support typeof débloque un problème de longue date dans l'écosystème vue-i18n et constitue le premier changement côté Oxc du cycle avec un contributeur Vue sur la PR." - question: "La version crates v0.138 livre-t-elle d'autres travaux de performance notables ?" answer: "Oui. Les cinq entrées de perf à côté de la mémoïsation `value_type` qui se distinguent : `semantic: Flatten hoisting_variables to avoid per-scope map allocation` (#23927, Lawrence Lin), qui supprime une allocation de map par scope à chaque mise à jour de variable hissée ; `isolated-declarations: Pool scope maps to avoid per-scope alloc/rehash` (#23761, Boshen), qui mutualise les scope maps utilisés par isolated-declarations pour éviter l'alloc/rehash par fonction ; `minifier: Bail member-expr folding before the side-effect walk` (#23924, Lawrence Lin), qui plie les cas simples des chaînes `a.b.c.d` avant la marche des effets de bord ; `parser: Avoid span lookup for arrow expression body` (#23788, camc314) ; et `formatter_core: Add printable-ASCII fast path to TextWidth` (#23913, Lawrence Lin), qui offre au calcul de largeur de ligne du formateur un fast path quand le texte ne contient que de l'ASCII imprimable. Côté parser, la plus grande entrée de perf est `parser: Allocate AST nodes in arena directly` (#23712, overlookmotel), faisant partie d'un cluster de trois PR (#23710 dans minifier, #23709 dans isolated-declarations, plus la PR parser) qui déplace l'allocation de nœuds AST hors de `Box::new_in` vers une allocation d'arène directe." - question: "Le cycle v0.138 est-il un bon moment pour migrer vers Oxlint / Oxfmt ?" answer: "Pour les utilisateurs JS / TS, la migration est en régime établi depuis plusieurs cycles et v1.72 / v0.57 ne changent rien : la surface CLI, le schéma de configuration, et les règles sont inchangés ; les gains de perf v1.72 arrivent automatiquement ; et les changements cassants d'Oxfmt v0.57 sont restreints à l'API Rust. Le meilleur argument pour migrer vers oxfmt spécifiquement en v0.57 est le retrait du repli Prettier : CSS / LESS / SCSS / css-in-js et GraphQL sont maintenant formatés par l'implémentation Rust propre d'Oxc plutôt qu'un Prettier groupé, ce qui comble un écart de longue date. L'argument contre la migration reste inchangé par rapport aux cycles précédents : toute règle qui vit dans ESLint et n'a pas encore été portée vers oxlint nécessite toujours un passage ESLint. Les guides officiels `migrate-from-prettier` et `migrate-from-eslint` couvrent le flux de travail ; la commande Oxfmt `--migrate prettier` (remise au propre dans #23963 ce cycle) fait l'essentiel de la traduction de configuration." --- [Oxlint apps_v1.72.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.72.0) et [oxfmt apps_v0.57.0](https://github.com/oxc-project/oxc/releases/tag/apps_v1.72.0) sont sortis ensemble dans la soirée du 29 juin 2026, sur la base de [crates_v0.138.0](https://github.com/oxc-project/oxc/releases/tag/crates_v0.138.0). Cette version est le cycle v0.138 que les [notes de version v1.71](/articles/2026-06-23--oxlint-v1-71-oxfmt-v0-56) prédisaient explicitement : « la dernière [version apps] avant la version crates v0.138 qui arrivera lundi 2026-06-29 ». Le cycle achève la migration AstBuilder qui courait sur les versions v0.135 à v0.137, retire le repli Prettier pour CSS / LESS / SCSS et GraphQL dans oxfmt, et livre la plus grande entrée de perf unique de l'étirement v0.137 → v0.138 : la mémoïsation `value_type` qui transforme une chaîne d'addition arithmétique de 20 000 termes de 6,1 secondes à 4,7 millisecondes. Cet article couvre la version apps Oxlint v1.72.0, la version apps Oxfmt v0.57.0, et la version crates_v0.138.0 ensemble parce que les trois sont conçues pour sortir comme un tout. Oxlint et oxfmt récupèrent la dernière ligne crates au moment de la version, et les changements cassants de ce cycle sont concentrés dans la couche crates. ## Unification AstBuilder : la migration v0.135 → v0.138 aboutit La plus grande histoire du cycle v0.138 est l'unification des anciennes et nouvelles API `AstBuilder` dans le crate `oxc_ast`. La migration court depuis au moins v0.135 début juin et constitue le plus grand changement d'API interne qu'Oxc ait fait depuis la réécriture du minifier. Le pattern est de cinq PR dans cette version qui déplacent la surface API vers un builder unique. [#23876](https://github.com/oxc-project/oxc/pull/23876) (overlookmotel) restreint le module `oxc_ast::builder` à exporter uniquement le type `AstBuilder` et la sentinelle `NONE`. [#23834](https://github.com/oxc-project/oxc/pull/23834) (overlookmotel) fait passer `oxc_ecmascript` à la nouvelle `AstBuilder`. [#23831](https://github.com/oxc-project/oxc/pull/23831) (overlookmotel) fait passer le transformer à la nouvelle `AstBuilder`. [#23875](https://github.com/oxc-project/oxc/pull/23875) (overlookmotel) supprime la duplication interne en unifiant les builders. [#23877](https://github.com/oxc-project/oxc/pull/23877) (overlookmotel) marque les méthodes `AstBuilder` héritées comme `#[deprecated]`. Le cycle ajoute aussi un flag de feature Cargo `disable_old_builder` pour `oxc_ast` (#23886, #23888) afin que les crates en aval puissent activer le flag et voir ce qui casse avant que les méthodes héritées ne soient supprimées. Le côté allocateur reçoit son propre lot de changements. [#23675](https://github.com/oxc-project/oxc/pull/23675) (overlookmotel) renomme le trait `AllocatorAccessor` en `GetAllocator`. [#23676](https://github.com/oxc-project/oxc/pull/23676) (overlookmotel) fait passer `GetAllocator::allocator` à `&self` au lieu de `self`. [#23781](https://github.com/oxc-project/oxc/pull/23781) (overlookmotel) fait prendre `&GetAllocator` aux méthodes `Str` et `Ident`. Ensemble, les trois changements achèvent la migration vers une API d'allocateur par emprunt : les appelants n'ont plus besoin de cloner ou de posséder un allocateur pour construire des chaînes et des identifiants. Pour les utilisateurs d'oxlint et oxfmt, rien de tout cela n'est visible. Pour les crates en aval qui construisent des couches AST personnalisées sur Oxc, c'est le plus grand changement cassant en trois cycles. Les notes de version signalent la fenêtre de migration : les méthodes héritées portent des annotations `#[deprecated]` maintenant, compileront avec des avertissements, et seront supprimées dans un cycle futur. L'équipe signalait cela depuis deux cycles, les notes de version v0.137 avertissant déjà du changement cassant dans `oxc_ast`. ## L'entrée de perf phare : la mémoïsation `value_type` transforme O(n²) en O(n) La plus grande entrée de perf visible par l'utilisateur en v0.138 est la [PR #23929](https://github.com/oxc-project/oxc/pull/23929) (Dunqing) : `perf(minifier): memoize value_type to remove its O(n^2) re-walk on long binary chains`. Le peephole post-order du minifier évalue `Expression::value_type` à chaque nœud, et sur une longue chaîne binaire associative à gauche l'évaluation parcourt à nouveau tout le sous-arbre gauche (`to_primitive` → `value_type` → `to_primitive` → …). Pour N nœuds le coût total était O(N²), et le cas dominant est celui des chaînes d'addition arithmétique non repliables : un `a + a + … + a` de 20 000 termes prenait 6 118 ms à minifier tandis que les phases de parsing et de sémantique étaient linéaires. Le correctif mémoïse `value_type` par adresse de nœud sur `MinifierState`, avec un point de coupure unique à la méthode récursive `Expression::value_type`. Chaque nœud est calculé une seule fois, donc le coût total devient O(N) amorti. Le cache est exposé comme hooks opt-in sur `GlobalContext` (`cached_value_type` / `cache_value_type`), et seul le `TraverseCtx` du minifier fournit un vrai cache. Tout autre appelant (`WithoutGlobalReferenceInformation`, la passe d'évaluation de constantes, l'analyse d'effets de bord, le harnais unitaire `value_type`) conserve le comportement non mis en cache exact précédent. Le cache est vidé au point unique de mutation (`record_mutation`, touché par chaque `replace_*` / `drop_*`) et à chaque reset par passe. Les chiffres, directement tirés de la description de la PR : | entrée | avant | après | effet | | --- | ---: | ---: | --- | | `a + a + …` × 4 000 | 234 ms | 0,9 ms | passage à l'échelle 4,07x → 2,09x (O(n²) → O(n)) | | `a + a + …` × 8 000 | 953 ms | 1,9 ms | linéaire à partir d'ici | | `a + a + …` × 20 000 | 6 118 ms | 4,7 ms | ≈1300x plus rapide | | antd.js (code réel) | 78,1 ms | 65,4 ms | ≈16% plus rapide sur entrée réelle | Le point clé est que les chaînes d'addition arithmétique sur la sortie minifiée (celles qu'on trouve dans le code numérique généré et dans les gros polyfills) chutent de trois ordres de grandeur. Les bundles réels chutent de 16% au premier passage, les gains se composant sur des entrées plus grandes. Le cycle comporte cinq autres entrées de perf qui méritent d'être signalées. [`semantic: Flatten hoisting_variables to avoid per-scope map allocation`](https://github.com/oxc-project/oxc/pull/23927) (Lawrence Lin) supprime l'allocation de map par scope qui se déclenchait à chaque mise à jour de variable hissée. [`isolated-declarations: Pool scope maps to avoid per-scope alloc/rehash`](https://github.com/oxc-project/oxc/pull/23761) (Boshen) mutualise les scope maps utilisés par `oxc_isolated_declarations` pour que l'alloc/rehash par fonction disparaisse. [`minifier: Bail member-expr folding before the side-effect walk`](https://github.com/oxc-project/oxc/pull/23924) (Lawrence Lin) plie les cas simples des chaînes `a.b.c.d` avant la marche des effets de bord. [`parser: Avoid span lookup for arrow expression body`](https://github.com/oxc-project/oxc/pull/23788) (camc314) supprime une recherche de hashmap par expression fléchée. Côté formateur, [`formatter_core: Add printable-ASCII fast path to TextWidth`](https://github.com/oxc-project/oxc/pull/23913) (Lawrence Lin) offre au calcul de largeur de ligne du formateur un fast path quand le texte est de l'ASCII imprimable pur, ce qui couvre la grande majorité de la sortie formatée. Il y a aussi un cluster de trois PR qui déplacent l'allocation de nœuds AST hors de `Box::new_in` vers une allocation d'arène directe : [`parser: Allocate AST nodes in arena directly`](https://github.com/oxc-project/oxc/pull/23712) (overlookmotel), [`minifier: Allocate AST nodes in arena directly`](https://github.com/oxc-project/oxc/pull/23710) (overlookmotel), et [`isolated_declarations: Allocate AST nodes in arena directly`](https://github.com/oxc-project/oxc/pull/23709) (overlookmotel). Ensemble, ils remplacent l'indirection `Box::new_in` par une écriture directe en bump allocator, supprimant une allocation heap par nœud AST dans le parseur, le minifier, et le pipeline isolated-declarations. ## Oxfmt v0.57 retire le repli Prettier pour CSS / LESS / SCSS / GraphQL Le plus grand changement structurel d'oxfmt est le retrait du repli Prettier pour les grammaires CSS et GraphQL. Avant v0.57, oxfmt pouvait formater les fichiers CSS / LESS / SCSS et GraphQL, mais le faisait en déléguant à un Prettier groupé pour ces grammaires. v0.57 retire le repli et formate les deux grammaires nativement en Rust. Le côté CSS arrive sous le nom d'[`oxc_formatter_css`](https://github.com/oxc-project/oxc/pull/23320) (leaysgur) et est connecté via l'entrée BREAKING [`Format parser:css,less,scss files + css-in-js by oxc_formatter_css`](https://github.com/oxc-project/oxc/pull/23321) (leaysgur). Le crate est une implémentation de formateur autonome qui prend les parseurs CSS / LESS / SCSS existants, parcourt l'AST, et émet une sortie compatible Prettier. Les notes de version mentionnent explicitement le css-in-js comme pris en charge : les template literals de style `styled-components` et Emotion, qu'oxfmt détecte déjà et route vers le parseur CSS, sont maintenant formatés par `oxc_formatter_css` plutôt que par le shim Prettier. Le côté GraphQL arrive sous le nom d'[`oxc_formatter_graphql`](https://github.com/oxc-project/oxc/pull/23317) (leaysgur) et est connecté via l'entrée BREAKING [`Support draft syntax with removing prettier fallback`](https://github.com/oxc-project/oxc/pull/23326) (leaysgur). La partie « draft syntax » est la partie vraiment nouvelle : l'implémentation GraphQL précédente d'oxfmt gérait la spec stable 2021 ; la nouvelle gère la syntaxe draft GraphQL October 2021 et la syntaxe working-draft utilisée par Apollo Federation et Yoga. C'est une vraie fonctionnalité, pas juste un renommage : le repli Prettier ne pouvait pas non plus gérer la draft syntax, donc la mise à niveau comble aussi un vrai écart format-on-save pour les utilisateurs sur la stack Apollo. Deux PR de parité avec Prettier rapprochent la sortie des nouveaux formateurs de celle de Prettier : [`formatter_css: Improve major prettier diffs`](https://github.com/oxc-project/oxc/pull/23327) (leaysgur) et [`formatter_graphql: Improve major prettier diffs`](https://github.com/oxc-project/oxc/pull/23419) (leaysgur). Les notes de version signalent que des diffs réels sur les bases de code existantes sont encore attendus (le pattern typique « premier passage change quelques lignes, passages suivants idempotents »), mais l'écart est bien plus petit qu'il ne l'était en v0.56. La version ajoute aussi [`formatter_css: Handle frontmatter language`](https://github.com/oxc-project/oxc/pull/23819) (leaysgur), qui route le frontmatter Markdown dans les fichiers CSS (par exemple le bloc `---` en haut du bloc `