Prettier

Qu’est-ce que Prettier ?

Prettier est un formateur de code opinioné. Il analyse votre code pour le transformer en arbre de syntaxe, puis le réécrit avec une mise en page déterministe, en ignorant les espaces blancs que vous avez saisis. Le résultat dépend uniquement de la structure du code et d’un petit ensemble d’options, ce qui garantit qu’une même entrée produira toujours la même sortie.

Ce déterminisme est tout l’intérêt de l’outil. Les débats sur le style disparaissent car c’est le formateur qui décide, et non l’équipe. Les diffs se concentrent sur les changements réels plutôt que sur des modifications d’espacement, et les relecteurs peuvent consacrer leur temps à la logique et à la conception. Prettier est l’un des rares outils qui réduit concrètement les frictions au sein d’une base de code.

Configuration

Prettier fonctionne sans aucune configuration, mais vous pouvez définir quelques options dans .prettierrc.

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2,
  "arrowParens": "always"
}

Ce sont les options les plus couramment modifiées par les équipes. Au-delà de celles-ci, Prettier prend les décisions. Moins vous définissez d’options, plus le résultat sera cohérent d’un projet à l’autre et moins vous aurez de maintenance à effectuer.

Exécuter Prettier

Formatez vos fichiers directement ou vérifiez-les sans modifier le contenu.

npx prettier --write .
npx prettier --check .
npx prettier --write src/app.tsx

--write reformate et sauvegarde les fichiers ; --check signale les fichiers qui seraient modifiés et renvoie un code de sortie non nul, ce qui est exactement ce dont la CI a besoin. Ajoutez un script pour que les commandes soient cohérentes.

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Ignorer des fichiers

.prettierignore liste les chemins à ignorer, en utilisant la même syntaxe que .gitignore.

dist
coverage
pnpm-lock.yaml
*.generated.ts

Il est important d’ignorer les fichiers de build et les fichiers générés : les formater crée du bruit qui sera écrasé lors du prochain build, et cela peut même casser la génération de code qui attend une structure spécifique.

Intégration à l’éditeur

Installez l’extension Prettier pour votre éditeur et activez le formatage à l’enregistrement (format on save). C’est là que Prettier est le plus rentable : vous ne vous souciez plus jamais du formatage, et chaque enregistrement laisse le fichier propre. Cela signifie également que vous pouvez utiliser --check en CI en toute confiance, car le formatage s’effectue en continu plutôt que lors d’un grand nettoyage final.

Travailler avec ESLint

Prettier et ESLint ont des règles de style qui se chevauchent, et s’ils sont laissés tels quels, ils entreront en conflit. La solution standard consiste à laisser Prettier gérer le formatage et à désactiver les règles ESLint conflictuelles.

// eslint.config.js
import js from "@eslint/js";
import prettier from "eslint-config-prettier";

export default [js.configs.recommended, prettier];

eslint-config-prettier désactive toutes les règles ESLint qui pourraient entrer en conflit avec Prettier, permettant ainsi à ESLint de se concentrer sur la qualité du code et à Prettier sur la mise en page. Si vous souhaitez que les problèmes de formatage apparaissent comme des erreurs de linting, eslint-plugin-prettier exécute Prettier en tant que règle, bien que de nombreuses équipes préfèrent garder les deux séparés.

Hooks de pré-commit

Le formatage avant un commit permet de garder la CI au vert et l’historique propre.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

Combiné à un exécuteur de hooks tel que husky, cela permet de formater uniquement les fichiers indexés (staged), afin que les commits restent rapides. C’est une petite configuration qui permet d’éviter toute une catégorie de commentaires de revue de code concernant le “code non formaté”.

Le rôle de Prettier

Prettier s’occupe uniquement du formatage. Il ne détecte pas les bugs, n’impose pas de types et ne vérifie pas les imports — ces tâches incombent à ESLint et au vérificateur de types. Une chaîne d’outils saine utilise les trois : Prettier pour la mise en page, ESLint pour la qualité et TypeScript pour les types. Chacun a un rôle précis, et aucun n’entre en conflit avec les autres.

Bonnes pratiques

• Acceptez les valeurs par défaut, à moins que votre équipe n’ait une raison valable d’en modifier une.
• Commitez un .prettierrc pour que chaque éditeur et chaque exécution CI soient synchronisés.
• Ajoutez .prettierignore pour les sorties de build et les fichiers générés.
• Configurez le formatage automatique à la sauvegarde dans l’éditeur.
• Exécutez --check dans la CI et --write via un hook de pre-commit.
• Désactivez les règles ESLint conflictuelles avec eslint-config-prettier.
• Gardez la liste des options courte.

Erreurs courantes

• Laisser ESLint et Prettier formater le code simultanément, ce qui crée des conflits.
• Formater des fichiers générés, ce qui pollue les diffs.
• Sauter la vérification CI, permettant ainsi la fusion de code non formaté.
• Modifier les options par projet sans raison valable, nuisant à la cohérence entre les projets.
• Exécuter Prettier sur l’ensemble du repo via un hook de pre-commit, ce qui ralentit les commits.
• Utiliser Prettier pour imposer des règles sémantiques qui relèvent de ESLint.

Et après ?

Prettier élimine toute une catégorie de tâches répétitives et fastidieuses. Associez-le à ESLint pour la qualité du code, à TypeScript pour la sécurité du typage, et intégrez les deux à votre projet Vite ainsi qu’à votre CI. Configurez ensuite le formatage automatique à la sauvegarde (« format on save ») et ne vous souciez plus jamais des espaces.