Formateur JavaScript

Prettier n'est pas simplement l'inspiration pour la sortie de formatage de cet outil — c'est le paquet Prettier lui-même, téléchargé et exécuté dans votre navigateur plutôt que via Node sur un serveur, donc le résultat est identique octet par octet à ce que produirait exécuter `npx prettier` localement avec la même configuration. Cette distinction compte car le formatage JavaScript est réellement difficile à approximer : bien le faire nécessite d'analyser complètement le langage, pas de le faire correspondre à des motifs, et un formateur qui n'approxime que le comportement de Prettier divergera de la configuration Prettier réelle d'un projet exactement dans les cas limites où cela compte — dans un décorateur, un type générique complexe, ou une expression JSX inhabituelle.

JavaScript contient plusieurs constructions qui font échouer directement une approche simple de comptage d'accolades et de points-virgules. Les littéraux de template peuvent contenir du texte arbitraire entre accents graves, y compris des caractères ressemblant exactement à du code — `` `function() { return "not real code"; }` `` est une seule valeur de chaîne, pas trois instructions, et un formateur qui ne suit pas les limites des littéraux de template le méprendra. Les littéraux d'expression régulière sont pires : `/{}/` contient des caractères ressemblant à des accolades mais faisant partie du motif de l'expression régulière elle-même, pas de la syntaxe structurelle. L'insertion automatique de points-virgules ajoute une troisième couche de difficulté, car JavaScript permet d'omettre les points-virgules dans de nombreux contextes et déduit où une instruction se termine selon des règles qu'un formateur naïf basé sur les lignes n'a aucun moyen de reproduire correctement. Analyser réellement le langage en un arbre de syntaxe adéquat, comme le fait Prettier, est ce qui évite les trois modes d'échec — un formateur raccourci qui se trompe même sur un seul en code de production est un risque, pas une commodité.

Prettier formate du code — standardise espaces blancs, sauts de ligne, style de guillemets et choix présentationnels similaires — et ne vérifie explicitement pas si le code est correct, sûr côté types, ou exempt d'erreurs. Un fichier avec une erreur de type, une référence à une variable indéfinie, ou une erreur logique se formate sans se plaindre tant qu'il est syntaxiquement valide, car formater et vérifier les types sont des préoccupations séparées gérées par des outils séparés. Le compilateur TypeScript lui-même, ou un linter comme ESLint, est là où la correction est vérifiée ; le travail de cet outil se termine en rendant le code au style cohérent et lisible.

Tabulations contre espaces, guillemets simples contre doubles, points-virgules ou non — aucun de ces choix n'affecte significativement l'exécution du code, et les désaccords à leur sujet consommaient auparavant un vrai temps dans des discussions de revue de code qui n'avaient rien à voir avec la correction. La vraie proposition de valeur de Prettier est d'éliminer complètement ce débat de la table : un petit ensemble de règles de formatage avec parti pris appliquées automatiquement et identiquement partout signifie que le débat se résout une fois, dans la configuration, plutôt que répétitivement à chaque pull request par la suite.

Chaque option exposée ici — largeur d'indentation, points-virgules, style de guillemets — reflète un vrai réglage de configuration Prettier, donc coller du code d'un projet avec un `.prettierrc` connu et faire correspondre ces mêmes réglages ici reproduit exactement ce que produirait l'outil du projet lui-même, sans avoir besoin d'installer quoi que ce soit localement juste pour vérifier comment un fragment serait formaté.