Prettier 3.7.0 : La fin du débat sur les ternaires et le CSS Nesting natif

On a souvent une relation amour-haine avec Prettier. On l'aime parce qu'il met fin aux débats stériles en Code Review sur les points-virgules. On le déteste parfois quand il décide de casser une belle chaîne de méthodes en un bloc illisible de 15 lignes.

La version 3.7.0, sortie fin novembre 2025, semble avoir écouté ces frustrations. L'équipe a fait un travail de fond non pas sur la "cosmétique", mais sur l'intelligence de compréhension de l'AST (Abstract Syntax Tree).

Si vous hésitiez à mettre à jour votre CI/CD, voici pourquoi vous devriez le faire, surtout si vous faites du TypeScript avancé ou du CSS moderne.

Les "Curious Ternaries" deviennent la norme

C'était l'arlésienne depuis la version 3.1 (expérimentale). La gestion des opérateurs ternaires imbriqués a toujours été le point faible de Prettier. Vous connaissez ce code illisible où tout est aligné à gauche, rendant la logique impossible à suivre ?

Avec la 3.7.0, le formatage "Curious Ternaries" (inspiré du style de code fonctionnel) est activé par défaut et affiné.

Avant (Le chaos plat) :

const message = isError
  ? "Une erreur est survenue"
  : isLoading
  ? "Chargement..."
  : data.length === 0
  ? "Aucune donnée"
  : "Voici vos données";

C'était difficile à scanner visuellement car les ? et les : se mélangeaient au début des lignes.

Maintenant (Prettier 3.7) :

const message =
  isError ? "Une erreur est survenue"
  : isLoading ? "Chargement..."
  : data.length === 0 ? "Aucune donnée"
  : "Voici vos données";

Notez la différence subtile mais cruciale : l'opérateur est fluide. On lit cela presque comme un switch/case ou un if/else if. Pour nous développeurs React qui abusons du rendu conditionnel dans le JSX, c'est un gain de lisibilité immédiat.

Support natif et intelligent du CSS Nesting

En 2025, le CSS Nesting est supporté par tous les navigateurs majeurs. Nous avons (presque) arrêté d'utiliser Sass pour ça. Mais Prettier avait du mal à formater correctement ces imbrications natives, qui diffèrent légèrement de la syntaxe SCSS.

La version 3.7 corrige le tir. Elle détecte désormais contextuellement si vous écrivez du CSS pur ou du préprocesseur.

/* style.css */
.card {
  background: white;
  /* Prettier 3.7 comprend que le '&' n'est plus obligatoire partout */
  @media (width >= 500px) {
    padding: 2rem;
  }
  /* Formatage propre des sélecteurs imbriqués */
  .title {
    font-weight: bold;
  }
}

Le gain n'est pas juste visuel, il est structurel. Prettier arrête d'essayer d'ajouter des indentations inutiles ou de casser les lignes sur les nouvelles query de conteneurs (@container).

TypeScript 5.7+ et le mot-clé satisfies

L'opérateur satisfies est devenu omniprésent dans nos codes TypeScript pour valider un type sans l'élargir (type widening). Cependant, lorsqu'il était utilisé dans des conditions complexes ou des définitions d'objets massives, Prettier avait tendance à le rejeter en bout de ligne ou à le casser bizarrement.

La 3.7 introduit une heuristique pour garder le satisfies collé à l'objet qu'il qualifie, même si cela dépasse légèrement la printWidth.

Exemple d'amélioration :

// Avant, Prettier pouvait isoler le satisfies sur une nouvelle ligne orpheline
const config = {
  // ... 50 lignes de config
} 
satisfies Config;
// Maintenant, il favorise la cohésion
const config = {
   // ... 50 lignes de config
} satisfies Config;

C'est un détail, mais quand vous scannez un fichier de 500 lignes, savoir immédiatement qu'un objet est contraint par un type est vital.

Performance : Moins de mémoire, plus de vitesse

C'est le point critique. Sur les monorepos massifs (Turborepo / Nx), Prettier est souvent le goulot d'étranglement du pipeline de linting.

Bien que Prettier ne soit pas encore réécrit en Rust (le rêve de beaucoup), la version 3.7 optimise drastiquement le parcours de l'AST pour les fichiers JavaScript et JSON. L'équipe annonce une réduction de l'empreinte mémoire de près de 15% sur les gros fichiers JSON (comme les package-lock.json ou les fichiers de traduction).

Si vous avez des scripts de CI qui échouent avec des erreurs JavaScript heap out of memory lors du formatage, cette mise à jour pourrait régler le problème sans avoir à augmenter la RAM de vos conteneurs.

Comme le changement sur les ternaires est visuellement impactant, si vous mettez à jour Prettier sur un projet existant comportant des milliers de fichiers, attendez-vous à un "Diff" massif lors de votre prochaine Pull Request.

Ma recommandation :

1. Verrouillez la version dans votre package.json : "prettier": "3.7.0".

2. Annoncez à votre équipe que le formatage va changer.

3. Faites un commit unique dédié à la migration de formatage (utilisez .git-blame-ignore-revs pour ne pas polluer l'historique Git).

Prettier 3.7 prouve qu'un outil "opinionated" peut changer d'avis quand l'expérience développeur l'exige. C'est une version de maturité qui rend le code moderne (ES2025) plus agréable à lire.