Configurer Prettier avec Claude Code

Quand Claude Code commence à modifier un vrai projet, le formatage n’est plus un détail esthétique. Une seule tâche peut toucher des composants, des tests, des fichiers JSON, du Markdown et la configuration CI. Si le diff mélange indentation, guillemets, retours ligne et virgules finales, la revue devient bruyante avant même de regarder le comportement.

Prettier est un formateur de code. Autrement dit, il réécrit l’apparence des fichiers pris en charge sans décider si la logique métier est correcte. Cette séparation est saine: Prettier s’occupe de la forme, tandis que les tests, TypeScript et ESLint s’occupent du comportement et des règles de qualité.

Ce guide met en place une configuration Prettier adaptée à Claude Code: installation locale, .prettierrc, .prettierignore, scripts npm, réglages VS Code, vérification CI, formatage des fichiers staged et instructions projet pour que Claude Code respecte les règles. Les exemples ciblent un projet npm JavaScript ou TypeScript courant.

Vue d’ensemble

Prettier fonctionne mieux comme une petite barrière de qualité placée à plusieurs endroits, pas comme une commande de nettoyage lancée quand on y pense.

flowchart LR
  A["Claude Code modifie"] --> B[".prettierrc fixe les règles"]
  B --> C["VS Code formate à l'enregistrement"]
  C --> D["npm run format:check"]
  D --> E["lint-staged traite les staged files"]
  E --> F["CI vérifie la PR"]

Chaque couche a son rôle. .prettierrc définit la politique de formatage. .prettierignore protège les fichiers générés ou hors périmètre. Les scripts de package.json donnent les mêmes commandes aux développeurs, à Claude Code et à CI. VS Code corrige pendant l’édition. lint-staged limite le changement aux fichiers du commit. CI bloque les oublis avant la revue.

Claude Code peut suivre une consigne textuelle, mais les préférences de formatage ne doivent pas vivre uniquement dans une conversation. Placez-les dans le dépôt, avec des commandes vérifiables.

Installer Prettier localement

Installez Prettier comme dépendance de développement locale. Le guide officiel Prettier Install recommande une installation locale avec version exacte afin que chaque environnement produise le même résultat.

npm install --save-dev --save-exact prettier

Au moment de l’introduction, exécutez une première passe complète.

npx prettier . --write

Dans un projet existant, gardez cette première passe dans un commit ou une pull request dédiée. Mélanger un formatage global avec une fonctionnalité rend la revue plus lente et complique l’analyse si un bug apparaît. Une fois la base nettoyée, Claude Code peut travailler sur des changements plus ciblés.

Ajouter .prettierrc

Prettier accepte plusieurs formats de configuration: .prettierrc, prettier.config.mjs ou une clé prettier dans package.json. La documentation officielle Configuration File explique que Prettier cherche la configuration depuis le fichier traité vers les dossiers parents, et qu’il n’utilise pas de configuration globale. C’est ce qui rend le comportement reproductible.

Pour commencer, un fichier JSON .prettierrc est clair et facile à relire.

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "bracketSpacing": true,
  "bracketSameLine": false,
  "arrowParens": "always",
  "endOfLine": "lf",
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "proseWrap": "always"
      }
    },
    {
      "files": ["*.yml", "*.yaml"],
      "options": {
        "singleQuote": false
      }
    }
  ]
}

printWidth est une indication pour Prettier, pas une limite absolue. endOfLine: "lf" réduit les différences entre Windows, macOS, Linux et CI. trailingComma: "all" diminue souvent la taille des diffs quand on ajoute un élément dans un objet ou un tableau.

Si le projet utilise beaucoup Tailwind CSS, vous pouvez évaluer prettier-plugin-tailwindcss plus tard. Évitez de commencer avec trop de plugins: stabilisez d’abord le formateur de base, puis ajoutez seulement ce qui répond à un besoin réel.

Définir .prettierignore

.prettierignore indique à Prettier ce qu’il ne doit pas réécrire. Utilisez-le pour les artefacts de build, caches, fichiers générés, fichiers minifiés et lockfiles contrôlés par les gestionnaires de paquets.

node_modules
dist
build
coverage
.next
.nuxt
.astro
.vercel
.cache
*.min.js
package-lock.json
pnpm-lock.yaml
yarn.lock

Prettier tient aussi compte de .gitignore lorsqu’il est lancé depuis le même dossier, mais les deux fichiers n’ont pas la même fonction. .gitignore décide ce que Git suit. .prettierignore décide ce que le formateur ne touche pas. Cette frontière explicite aide aussi Claude Code à ne pas modifier des fichiers qui ne sont pas dans le périmètre.

Un échec fréquent consiste à oublier un client API généré. Claude Code corrige un petit composant, puis prettier . --write reformate des milliers de lignes dans src/generated/. Pour du généré, modifiez la source ou le schema et régénérez. Ne cachez pas ce volume dans un diff de feature.

Ajouter des scripts npm

La documentation officielle npm présente scripts comme l’endroit où un package déclare ses commandes exécutables. Dans un flux Claude Code, cela donne un vocabulaire commun aux développeurs, à l’agent et à CI.

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

Utilisez la commande qui écrit en local, et la commande de vérification dans l’automatisation.

npm run format
npm run format:check

format modifie les fichiers. format:check vérifie seulement qu’ils sont déjà formatés et échoue sinon. En CI, format:check est plus lisible: le pipeline signale le problème sans réécrire du code non revu.

Configurer VS Code

Le formatage à l’enregistrement évite beaucoup de bruit avant le commit. Placez le réglage dans .vscode/settings.json afin que le dépôt porte la convention, au lieu de dépendre des préférences personnelles.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "prettier.requireConfig": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[mdx]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

prettier.requireConfig évite que l’extension formate des dépôts qui n’ont pas choisi Prettier. C’est particulièrement utile lorsque vous passez souvent d’un projet client à un autre.

Vérifier en CI

Un workflow GitHub Actions minimal suffit pour commencer.

name: format

on:
  pull_request:
  push:
    branches: [main]

jobs:
  prettier:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run format:check

Quand Claude Code met à jour une pull request, ce check retire un bruit mécanique avant la revue humaine. Pour les règles de qualité, combinez-le avec le guide ESLint pour Claude Code, mais gardez des signaux séparés pour formatage et lint.

Formater seulement les fichiers staged

Dans un grand dépôt, formater tout le projet à chaque commit peut être lent et créer des diffs non liés. Husky et lint-staged permettent de traiter seulement les fichiers ajoutés avec git add. Le flux complet est expliqué dans le guide Husky + lint-staged, voici la version minimale pour Prettier.

npm install --save-dev --save-exact husky lint-staged
npm pkg set scripts.prepare="husky"
npx husky init

Ajoutez cette configuration dans package.json.

{
  "scripts": {
    "prepare": "husky"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md,mdx,json,yml,yaml}": "prettier --write"
  }
}

Gardez .husky/pre-commit minimal.

npx lint-staged

Le principal avantage est le contrôle du périmètre. Si Claude Code modifie trois fichiers, le pre-commit formate ces trois fichiers, sans réveiller toute la dette historique du dépôt.

Donner les règles à Claude Code

Les instructions projet doivent être écrites dans CLAUDE.md. La documentation officielle Claude Code memory décrit ./CLAUDE.md et ./.claude/CLAUDE.md comme des fichiers partagés pour les commandes, standards de code et workflows.

## Formatting

- Read `.prettierrc` and `.prettierignore` before formatting files.
- Do not reformat unrelated files while implementing a feature.
- After changing JavaScript, TypeScript, CSS, Markdown, JSON, or YAML, run `npm run format:check`.
- Keep formatter-only changes separate from behavior changes.

Vous pouvez automatiser davantage avec les hooks Claude Code. Le guide officiel des hooks donne un exemple qui lance Prettier après les outils Edit ou Write.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Ce hook est pratique, mais il dépend de jq et du shell. Dans une équipe très Windows, commencez souvent par des instructions explicites dans CLAUDE.md et une exigence npm run format:check en fin de tâche. Ajoutez le hook partagé une fois l’environnement homogène.

Trois cas d’usage

Cas	Apport de Prettier	Demande à Claude Code
Application TypeScript	Composants, tests et types restent lisibles dans un seul diff	Lance npm run format:check après la modification.
Site Astro ou MDX	Frontmatter, Markdown, code fences et JSON restent cohérents	Vérifie que les code fences MDX sont encore valides.
Revue de PR en équipe	Les reviewers regardent le comportement plutôt que l’indentation	Ne mélange pas les changements de format seuls avec la feature.

Le cas MDX est très parlant. Un seul article peut contenir du texte, du frontmatter, des commandes shell, du JSON et du JSX. Sans Prettier, Claude Code peut produire un contenu correct mais irrégulier visuellement. Avec un formateur partagé, la revue revient sur l’exactitude et les exemples.

Pièges fréquents

Premier piège: utiliser npx prettier . --write sans installer Prettier. Si la dépendance n’est pas fixée, npx peut récupérer une version différente plus tard. Installez localement avec --save-exact.

Deuxième piège: laisser ESLint et Prettier se battre. Prettier formate. ESLint détecte les bugs potentiels et règles de maintenabilité. Si des règles de style entrent en conflit, regardez eslint-config-prettier.

Troisième piège: formater tout le dépôt dans une branche de feature. Si la base est désordonnée, faites d’abord un changement dédié au formateur, puis demandez à Claude Code d’éviter les fichiers non liés.

Quatrième piège: ignorer trop large. Une règle .prettierignore comme src/** annule l’intérêt du formateur. Ignorez les fichiers générés, caches, gros artefacts ou fichiers contrôlés par d’autres outils, pas le code quotidien.

CTA monétisation

Si vous utilisez Claude Code sur plusieurs projets, l’actif réutilisable n’est pas seulement .prettierrc. C’est le système complet: CLAUDE.md, commandes de vérification, checklist de revue, modèles de PR et notes de passation. ClaudeCodeLab rassemble ces ressources sur la page produits pour transformer cette configuration en standard réutilisable.

Conclusion

Prettier est une base simple mais importante pour travailler avec Claude Code. Installez-le localement, définissez .prettierrc, protégez les fichiers générés avec .prettierignore, exposez format et format:check, utilisez VS Code pour le feedback immédiat, vérifiez en CI et ajoutez lint-staged pour limiter le périmètre. Documentez ensuite la même attente dans CLAUDE.md.

Résultat testé: après application sur un petit projet TypeScript et MDX, la première passe a créé une base propre, npm run format:check est resté stable, et les modifications produites par Claude Code sont devenues plus faciles à relire. Les gains les plus nets venaient de l’exclusion des artefacts générés et de la séparation entre format et format:check.