Outil de Formatage YAML

Le formateur YAML rend les fichiers YAML plus lisibles grâce à indentation, retours à la ligne et structure visibles. YAML est fréquent dans les configurations CI, manifestes Kubernetes, Docker Compose, générateurs de sites statiques, localisation, fichiers OpenAPI et paramètres d’applications. Contrairement à JSON, YAML dépend fortement de l’indentation, des marqueurs de liste, deux-points, guillemets, ancres et chaînes multilignes; une petite erreur peut créer une structure différente. L’outil aide à lire, nettoyer et repérer des problèmes de syntaxe évidents, mais ne remplace pas la validation de schéma ni les contrôles propres aux outils. Pour Kubernetes, GitHub Actions, Ansible ou production, testez dans le système cible.

Le formatage YAML s'appuie sur la spécification YAML 1.2.2 (révisée en octobre 2021), qui définit formellement JSON comme un sous-ensemble strict de YAML — tout document JSON valide est analysable en tant que YAML. L'analyse se déroule en trois couches : une couche de présentation scanne les points de code Unicode et résout les séquences d'échappement ; une couche de sérialisation construit un graphe de nœuds de type scalaires, séquences et mappings ; une couche native applique le schéma Core de YAML pour convertir les scalaires dans les types résolus `!!str`, `!!int`, `!!float`, `!!bool`, `!!null`, `!!seq`, `!!map`. Les bibliothèques d'exécution courantes incluent js-yaml et le plus récent paquet `yaml` sur Node, PyYAML et ruamel.yaml sur Python, et SnakeYAML sur la JVM. Les formateurs côté navigateur analysent généralement en objet JS via `load`/`dump` de js-yaml et effectuent un aller-retour. L'indentation est la primitive fondamentale : seul l'espace ASCII (U+0020) est autorisé — la spécification interdit explicitement les caractères de tabulation (U+0009) pour l'indentation dans la section §6.1, ce pourquoi le copier-coller depuis un éditeur qui convertit automatiquement est la cause la plus fréquente d'échec d'analyse. Le style bloc détermine l'imbrication uniquement par la position en colonne, les nœuds enfants doivent donc être indentés davantage que leur parent d'au moins une espace (deux par convention). Le style flux emprunte la syntaxe JSON — `[1, 2, 3]` et `{a: 1, b: 2}` — et peut être imbriqué dans le style bloc pour les expressions sur une seule ligne. Les scalaires bloc utilisent le pliage piloté par des indicateurs : `|` (littéral) préserve les retours à la ligne exactement, `>` (plié) replie les retours à la ligne simples en espaces et conserve les lignes vides comme séparateurs de paragraphe, et les indicateurs de rognage `-` (supprimer les retours finaux) et `+` (conserver tous les retours finaux) se placent après l'indicateur (`|-`, `>+`). Les règles de citation diffèrent : les scalaires entre guillemets simples traitent `\` littéralement et utilisent `''` pour intégrer un guillemet ; les scalaires entre guillemets doubles respectent les séquences d'échappement de style C (`\n`, `\t`, `\uXXXX`). Les formateurs normalisent généralement vers un seul style de bloc et réémettent les ancres et alias. Une ancre `&name` marque un nœud ; un alias `*name` le référence ; la clé de fusion `<<: *name` (vestige de YAML 1.1 encore pris en charge par la plupart des analyseurs) importe les clés d'un autre mapping dans le mapping courant. Les flux multi-documents sont séparés par des marqueurs de début `---` et des marqueurs de fin `...` optionnels, le modèle utilisé par Kubernetes pour fournir plusieurs ressources dans un seul manifeste. Deux pièges bien connus méritent une ré-émission prudente : le problème de la Norvège — le scalaire non cité `no` est interprété comme `false` sous le schéma YAML 1.1 (et le code pays devient un booléen) — et CVE-2017-18342, où le `yaml.load` de PyYAML désérialisait des objets Python arbitraires, corrigé en passant à `safe_load`. Ce sont autant de raisons pour lesquelles un formateur doit traiter la résolution des scalaires avec prudence et ne jamais exécuter de constructeurs étiquetés. L'analyse est en O(n) par rapport à la longueur d'entrée ; les commentaires sont ignorés par la plupart des bibliothèques basées sur AST car ils ne font pas partie du modèle d'information YAML.

• Spécification : YAML 1.2.2 (oct. 2021). JSON est un sous-ensemble strict de YAML 1.2, tout document JSON valide s'analyse donc en YAML ; bibliothèques courantes : js-yaml, le paquet `yaml`, PyYAML, ruamel.yaml, SnakeYAML.
• L'indentation doit être un espace ASCII (U+0020) ; les caractères de tabulation (U+0009) sont interdits pour l'indentation par §6.1 — la cause la plus fréquente des erreurs `mapping values are not allowed here`.
• Style bloc vs flux : le bloc utilise l'imbrication par position en colonne (2 ou 4 espaces par convention) ; le flux utilise les syntaxes de type JSON `[1, 2, 3]` et `{a: 1}`. Les deux peuvent s'imbriquer.
• Scalars bloc : `|` littéral préserve les retours à la ligne, `>` plié replie les retours simples en espaces ; les indicateurs de rognage `-` (supprimer) et `+` (conserver) se placent après l'indicateur, ex. `|-`, `>+`.
• Les ancres `&name` marquent les nœuds, les alias `*name` les référencent, et la clé de fusion `<<: *name` importe les clés d'un autre mapping (vestige de YAML 1.1, pris en charge par la plupart des analyseurs).
• Les flux multi-documents sont séparés par des marqueurs `---` (début) et `...` (fin) optionnels — le modèle utilisé par Kubernetes pour fournir plusieurs ressources dans un seul manifeste.
• Pièges : le problème de la Norvège (`no`/`yes`/`on`/`off` non cités analysés comme des booléens sous le schéma YAML 1.1 ; le schéma Core YAML 1.2 corrige la plupart de ces cas) et CVE-2017-18342 (exécution de code arbitraire via `yaml.load` de PyYAML ; utiliser `safe_load`).