VS Code Format On Save - La solution pour un code impeccable

Automatiser le formatage à l’enregistrement dans VS Code évite une grande partie du bruit visuel dans un projet web, surtout quand plusieurs personnes touchent au même code. Le réglage vscode format on save correspond en pratique à un réflexe simple : laisser l’éditeur appliquer le bon formateur au moment de la sauvegarde, sans y penser à chaque fichier. Dans cet article, je détaille ce que fait exactement ce mécanisme, comment l’activer proprement, comment le limiter à un projet ou à un langage, et quoi vérifier quand rien ne se passe.

Ce que fait réellement le formatage à l’enregistrement

Quand je parle de formatage à l’enregistrement, je parle d’une opération très précise : VS Code prend le document courant, appelle le formateur actif pour ce langage, puis réécrit le fichier selon les règles de ce formateur. Cela ne corrige pas une logique métier, ne répare pas un bug et ne remplace pas un linter. En revanche, cela remet d’équerre l’indentation, les sauts de ligne, l’alignement et la structure visuelle du code, ce qui réduit les diffs inutiles et les relectures pénibles.

Il faut aussi distinguer ce mécanisme de l’auto-save. L’auto-save décide quand le fichier est enregistré, tandis que le formatage à l’enregistrement décide quoi faire juste avant ou pendant cette sauvegarde. En pratique, si vous testez un comportement étrange, je conseille toujours de commencer par une sauvegarde manuelle pour isoler le problème avant d’accuser l’auto-save. Une fois cette mécanique comprise, l’activation devient beaucoup plus simple.

Activer le formatage automatique dans VS Code

Je préfère activer ce réglage d’abord dans l’interface, puis le figer dans le fichier de configuration du projet quand le besoin est stable. Les deux chemins mènent au même résultat, mais la version JSON est plus fiable pour une équipe.

1. Ouvrez les paramètres de VS Code.
2. Cherchez Format On Save ou format on save.
3. Activez le réglage au niveau utilisateur si vous voulez l’avoir partout, ou au niveau workspace si vous travaillez sur un projet précis.
4. Si vous voulez une configuration reproductible, ouvrez le fichier settings.json du projet et ajoutez le réglage manuellement.

{
  "editor.formatOnSave": true
}

Pour un dépôt partagé, je mets souvent cette option dans .vscode/settings.json plutôt que dans mes préférences personnelles. Le bénéfice est simple : tout le monde voit le même comportement dès l’ouverture du projet, sans dépendre d’un profil local. Si un projet a plusieurs langages, je peux ensuite ajouter des ajustements par langage, mais je garde cette base très lisible.

À partir de là, la vraie question n’est plus “comment l’activer”, mais “où l’activer pour ne pas créer d’effets de bord”. C’est exactement ce qu’il faut clarifier ensuite.

Choisir la bonne portée pour le projet

Je ne configure pas le formatage à l’enregistrement au même niveau selon le contexte. Pour un test rapide, le réglage utilisateur suffit. Pour un dépôt d’équipe, je privilégie le workspace. Et si un langage a besoin d’un traitement spécifique, je passe par une surcharge ciblée.

Dans un projet web, je trouve cette hiérarchie particulièrement saine. Le réglage global garde le confort, le workspace garde la cohérence, et la surcharge par langage évite d’embarquer tout le monde dans le même comportement quand ce n’est pas pertinent. Si le dépôt suit aussi une convention partagée via un fichier de style ou un formateur de projet, je laisse cette source de vérité prendre le dessus sur les préférences locales.

Une fois la portée bien choisie, il reste à comprendre quels réglages doivent travailler ensemble et lesquels ne se remplacent pas les uns les autres.

Combiner le formatage avec les autres actions à la sauvegarde

Le piège classique, c’est de croire qu’un seul réglage gère tout. En réalité, VS Code sépare assez nettement le formatage, les actions de code et le formatage pendant la frappe ou le collage. Je m’en sers comme d’une boîte à outils, pas comme d’un interrupteur magique.

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports": "explicit"
  }
}

Ce duo est souvent suffisant pour un projet JavaScript ou TypeScript bien tenu : le formateur remet le code en forme, puis les actions sur la sauvegarde prennent en charge les imports ou d’autres corrections automatiques. Je réserve les réglages plus agressifs au moment où l’équipe en a vraiment besoin, parce qu’un excès d’automatisation finit vite par créer des surprises en relecture. La vraie difficulté, ensuite, c’est de diagnostiquer pourquoi tout semble bien configuré mais rien ne se passe.

Résoudre les blocages les plus fréquents

Quand le formatage à l’enregistrement ne réagit pas, je procède toujours dans le même ordre. Je vérifie le langage actif, le formateur par défaut, la portée du réglage, puis les éventuels conflits avec une autre extension. Dans la majorité des cas, le problème est là, pas dans VS Code lui-même.

Aucun changement ne se produit

• Vérifiez que editor.formatOnSave est bien à true dans la bonne portée.
• Ouvrez un fichier du bon type et regardez le langage affiché dans la barre d’état.
• Lancez Format Document à la main pour voir si un formateur répond au moins à cette commande.
• Si plusieurs formateurs existent, choisissez-en un comme formateur par défaut pour ce langage.
• Si vous travaillez dans un dépôt partagé, contrôlez que le workspace ne désactive pas le réglage localement.

Lire aussi : Code Markdown - Écrivez des blocs parfaits pour vos docs techniques

Le résultat existe, mais il n’est pas celui attendu

• Un autre formateur peut avoir pris le dessus sur celui que vous attendiez.
• Le langage détecté peut être faux, surtout sur des fichiers atypiques ou des extensions personnalisées.
• Le formatage peut être volontairement limité si vous avez activé un mode qui ne touche que les lignes modifiées.
• Sur de très gros fichiers, je teste d’abord la commande manuelle pour distinguer un problème de performance d’un problème de configuration.

Si rien n’aide, je coupe temporairement les extensions de formatage concurrentes pour isoler le coupable. C’est plus rapide que de modifier dix réglages à l’aveugle, et ça évite les faux diagnostics. Une fois cette méthode en place, je peux revenir à une configuration stable et prévisible, ce qui compte surtout sur un projet web où les fichiers changent vite.

La configuration que je garde pour un projet web

Pour un projet JavaScript ou TypeScript, je vise un réglage sobre, lisible et facile à partager. Je garde le formatage à l’enregistrement activé, j’ajoute les actions utiles sur les imports quand le projet en a besoin, et je laisse les règles plus précises au formateur ou aux fichiers de configuration du dépôt.

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports": "explicit"
  }
}

Ensuite, je ne multiplie les exceptions que si le projet les justifie réellement. Sur un dépôt d’équipe, c’est souvent la combinaison la plus saine : un formatage automatique discret, des diffs plus propres et moins de débat inutile sur l’indentation à chaque pull request. Pour garder cet équilibre, je préfère que les conventions de fond vivent dans le projet, et que VS Code ne fasse que les appliquer au bon moment.