Outil de Formatage JavaScript
Qu'est-ce que le formatage JavaScript ?
Le formateur JavaScript transforme du code JavaScript en une forme cohérente et lisible. Il organise indentation, retours à la ligne, blocs, objets littéraux, tableaux, appels de fonctions et expressions imbriquées afin de rendre logique et flux de données plus faciles à suivre. Il aide au débogage, à la revue de code, aux exemples pédagogiques, aux extraits copiés et aux fichiers minifiés ou générés. Le formatage n’est pas une analyse statique: il ne corrige pas les erreurs d’exécution, ne prouve pas la logique asynchrone, ne détecte pas toutes les dépendances risquées et ne remplace pas le linting. En projet réel, il doit s’aligner sur ESLint, Prettier ou les règles d’équipe.
Comment utiliser
Comment utiliser
- Collez ou saisissez du code JavaScript dans la zone de saisie de gauche
- Sélectionnez la taille d'indentation, le style de guillemets et les options de points-virgules
- Cliquez sur « Format » pour formater le code, ou « Validate » pour vérifier la syntaxe
- Consultez le résultat à droite (avec coloration syntaxique)
- Cliquez sur « Copy » pour copier dans le presse-papiers
Description des options
Raccourcis clavier
- Ctrl + EnterFormater
- Ctrl + Shift + CCopier le résultat
Conseils JavaScript
- Le formatage ne garantit pas l'exécution correcte. Relancez les tests ou vérifiez dans le navigateur après avoir modifié du JavaScript qui repose sur l'insertion automatique de points-virgules ou des transformations de build.
- Lors de la validation de code collé, gardez à l'esprit que la prise en charge du parseur du navigateur peut différer de votre environnement d'exécution cible ou de la configuration de votre bundler.
Cas d’utilisation
Principe technique
Un pretty-printer JavaScript est un pipeline en trois étapes défini par rapport à la grammaire ECMA-262 : un lexer produit un flux de tokens (IdentifierName, NumericLiteral, StringLiteral, TemplateHead/Middle/Tail, Punctuator, Keyword et LineTerminator) ; un parser construit un AST compatible ESTree (le format utilisé par @babel/parser, acorn et esprima) ; un printer parcourt l'arbre et émet du texte selon des règles pilotées par la taille d'indentation et la largeur d'impression cible. Prettier compile l'AST en une représentation intermédiaire Doc construite à partir des primitives group, indent, line et softline, puis un algorithme de disposition choisit les points de coupure pour que la sortie tienne dans printWidth (80, 100, 120). ESLint --fix réécrit quant à lui les tokens directement dans le source original, préservant plus agressivement les commentaires mais ne corrigeant que les règles qui optent pour l'autofix. Le printer ne peut pas insérer librement des retours à la ligne : l'ECMA-262 §11.9.1 Automatic Semicolon Insertion termine une instruction à chaque LineTerminator sauf si le token suivant est une continuation. Concrètement, couper avant une ligne commençant par `(`, `[`, `` ` ``, `+`, `-`, `/` ou un token `++`/`--` modifiera silencieusement la sémantique, et un retour à la ligne juste après `return`, `throw`, `break`, `continue` ou `yield` insère un point-virgule et abandonne l'opérande. Les template literals (backticks) préservent leurs octets intérieurs tels quels, y compris les expressions `${}` imbriquées dont l'intérieur est reformaté en JS mais dont les espaces environnants ne le sont pas. Les commentaires sont rattachés aux nœuds AST voisins via les tableaux leading/trailing/innerComments afin de survivre au cycle complet. Le lexing et l'impression sont tous deux en O(n) sur la longueur du source avec une petite constante ; le parser est effectivement linéaire pour du code bien formé grâce au lookahead à un token de la grammaire LR(1) de l'ECMA-262. L'analyse JavaScript standard ne couvre pas JSX, les annotations de types TypeScript, les décorateurs ni Flow, qui nécessitent les plugins de @babel/parser ou @typescript-eslint/parser ; exécuter un outil JS pur sur un fichier .tsx rejettera les annotations `: type`. Les source maps (Source Map v3) peuvent préserver le mapping ligne/colonne original lorsqu'une étape de build doit conserver la fidélité des stack traces, et les fins de ligne (LF vs CRLF) sont normalisées à l'écriture, pas au moment du parsing.
- Pipeline : lexer (flux de tokens selon ECMA-262 §12) -> ESTree AST (acorn/@babel/parser/esprima) -> printer ; lexer et printer en O(n), parser en O(n) avec lookahead à un token.
- Pièges d'ASI de ECMA-262 §11.9.1 : ne jamais couper une ligne avant un token commençant par `(`, `[`, `` ` ``, `+`, `-`, `/`, ou avant `++`/`--`, et ne jamais couper juste après `return`/`throw`/`break`/`continue`/`yield`.
- Prettier vs ESLint --fix : Prettier abaisse l'AST en un IR Doc (group/indent/line) et choisit des dispositions qui tiennent dans printWidth (80/100/120) ; ESLint --fix réécrit les tokens sur place et n'applique que les règles marquées fixer.
- Préservation des commentaires : leading/trailing/innerComments sont liés aux nœuds AST ; les blocs JSDoc juste au-dessus des déclarations restent rattachés pour que le printer ne les orpheline pas sur une instruction précédente.
- Les template literals (backticks) sont préservés octet par octet ; seul le JS à l'intérieur de `${}` est réimprimé. Les expressions régulières et les guillemets des littéraux chaîne sont normalisés selon le style choisi (guillemets simples/doubles) avec les échappements `\` recalculés.
- Couverture des dialectes : les parseurs JS purs rejettent JSX, les types TypeScript, les décorateurs et Flow ; les fichiers .tsx/.ts nécessitent les plugins @babel/parser ['jsx','typescript','decorators-legacy'] ou @typescript-eslint/parser.
- Normalisation de la sortie : fins de ligne écrites en LF ou CRLF selon la configuration (indépendamment de l'entrée), politique de virgules finales appliquée aux tableaux/objets/appels multilignes, et Source Map v3 émise lorsque la chaîne d'outils doit conserver les informations de ligne/colonne originales.
Exemples
Avant le formatage
function greet(name){if(!name){return 'Hello, stranger';}const greeting=`Hello, ${name}!`;console.log(greeting);return greeting;}Après le formatage (2 espaces)
function greet(name) {
if (!name) {
return 'Hello, stranger';
}
const greeting = `Hello, ${name}!`;
console.log(greeting);
return greeting;
}Après la minification
function greet(n){if(!n)return"Hello, stranger";const e=`Hello, ${n}!`;return console.log(e),e}FAQ
Quel style le formateur applique-t-il ?
La plupart des versions utilisent Prettier avec ses paramètres par défaut : largeur de ligne de 80 colonnes, points-virgules, guillemets doubles, indentation de 2 espaces, virgules finales lorsque c'est compatible ES5. Modifiez les options si votre projet utilise un style différent. Le résultat est déterministe pour une configuration donnée : même entrée, même sortie.
Le formateur exécute-t-il mon JS ?
Non. Il se contente d'analyser puis de réimprimer le code source. Les effets de bord, les appels réseau et les erreurs d'exécution n'ont aucune importance : le formateur n'exécute jamais le script.
Va-t-il corriger les erreurs de syntaxe ?
Non. L'analyseur refuse de formater du JavaScript invalide et indique l'endroit où l'analyse a échoué. Corrigez d'abord l'erreur de syntaxe ; les causes courantes sont des accolades manquantes, un point-virgule absent après un return d'IIFE, ou des template literals avec des backticks mal appariés.
JSX et TypeScript sont-ils pris en charge ?
La plupart des versions modernes analysent JavaScript avec JSX ainsi que la syntaxe TypeScript (.ts, .tsx). Le formateur détecte la syntaxe en fonction de ce qu'il analyse. Si vous travaillez en ES5 pur, désactivez le mode TypeScript pour éviter les faux positifs.
Peut-il minifier du JS ?
Certaines versions proposent un mode de minification (style Terser) qui renomme les variables, supprime les espaces et élimine le code mort. La sortie est compacte mais illisible. Utilisez la minification pour les builds de production, et le formatage pour la relecture du code source.
Mon code est-il téléversé ?
Non. L'analyse et l'impression s'exécutent dans votre navigateur via un analyseur basé sur JavaScript. Le code collé n'est pas transmis.
Pourquoi mes commentaires sont-ils légèrement déplacés ?
Prettier et les formateurs similaires rattachent les commentaires au nœud AST le plus proche. Un commentaire entre deux fonctions peut « appartenir » à la fonction du dessous dans l'AST et se retrouver réattaché. Les commentaires en fin de ligne sont en général préservés à l'identique ; les commentaires flottants peuvent se déplacer.