FracturedJson

 (github.com/j-brooke)
6 points par GN⁺ 2026-01-03 | 1 commentaires | Partager sur WhatsApp
  • Ensemble d’utilitaires de formatage qui organisent les données JSON pour les rendre lisibles tout en conservant une forme compacte
  • Les tableaux et objets sont représentés autant que possible sur une seule ligne, et lorsque les structures se ressemblent, ils sont alignés sous forme de tableau
  • Prend en charge la préservation des commentaires et conserve les commentaires, absents du standard JSON mais fréquents dans les usages réels
  • Utilisable dans divers environnements, notamment comme bibliothèque .NET, package JavaScript/TypeScript, extension VS Code et formateur pour navigateur
  • Un outil qui améliore les limites de lisibilité des formateurs JSON existants et renforce la compréhension visuelle des développeurs et analystes de données

Aperçu de FracturedJson

  • FracturedJson est un ensemble d’utilitaires qui génèrent un format JSON compact tout en restant facile à lire pour un humain
    • Les tableaux et objets sont affichés sur une seule ligne s’ils ne sont ni trop longs ni trop complexes
    • Les lignes multiples de structure similaire alignent les champs pour un affichage tabulaire
    • Les tableaux longs sont répartis sur plusieurs lignes avec plusieurs éléments par ligne
  • Le format de sortie peut être contrôlé via divers réglages, et dans la plupart des cas, les paramètres par défaut produisent déjà un résultat agréable à lire
  • Disponible sous forme de page de formatage dans le navigateur, de bibliothèque .NET, de package JavaScript/TypeScript et d’extension VS Code
  • Une option pour Python est également indiquée séparément

Motivation

  • La plupart des bibliothèques JSON ne proposent que deux formats
    • Minified JSON : efficace, mais difficile à lire pour un humain
    • Beautified/Indented JSON : trop étalé, ce qui rend la lecture rapide plus difficile
  • FracturedJson formate les données comme le ferait une personne en les écrivant directement
    • Sauf si elles sont trop complexes ou trop longues, les structures conteneurs restent sur une seule ligne
    • Les tableaux ou objets similaires sont alignés sous forme de tableau

Fonctionnement (How It Works)

  • FracturedJson utilise quatre types de formatage
    1. Inlined : représente sur une seule ligne les objets ou tableaux courts et simples
      • Le réglage MaxInlineComplexity contrôle le niveau d’imbrication autorisé
    2. Compact Multiline Array : place plusieurs éléments sur une même ligne tout en les répartissant sur plusieurs lignes
      • MaxCompactArrayComplexity permet d’ajuster la profondeur d’imbrication autorisée, avec -1 pour désactiver cette option
    3. Table : aligne les éléments de structure similaire en colonnes
      • Si les conteneurs internes sont trop complexes, seule une partie est condensée
      • Le comportement peut être contrôlé avec MaxTableRowComplexity et TableCommaPlacement
    4. Expanded : si aucune des conditions précédentes ne s’applique, chaque élément est affiché sur plusieurs lignes avec indentation

Gestion des commentaires

  • Le standard JSON n’autorise pas les commentaires, mais FracturedJson prend en charge une fonction de préservation des commentaires
    • Les commentaires sont conservés avec les éléments concernés, et les commentaires multiligne comme les commentaires en ligne sont tous deux pris en charge

Discussions

  • Un espace GitHub Discussions est proposé pour les questions des utilisateurs, les retours et les suggestions
  • Il permet d’échanger sur le projet et de proposer des améliorations

À lire aussi

1 commentaires

 
GN⁺ 2026-01-03
Commentaires sur Hacker News

  • Il existe actuellement deux implémentations maintenues de ce projet
    l’une est la version C# (FracturedJson .NET Library), l’autre la version TypeScript/JavaScript (FracturedJsonJs)
    Il existait aussi autrefois une version Python pure, mais elle n’est plus maintenue et a été remplacée par un wrapper Python autour du code C# (fractured-json)
    Cette version Python précise qu’elle nécessite le runtime .NET, ce qui a l’inconvénient de rendre l’installation difficile avec un simple pip install
    Je pense que c’est une bonne occasion de créer une conformance suite indépendante du langage — c’est-à-dire un ensemble de tests pilotés par les données permettant de vérifier que plusieurs implémentations se comportent de la même manière
    À noter que l’ancienne version Python utilisait déjà ce type de tests (données de test de compact-json)

    • Je viens justement de le porter en Rust et je compte le maintenir à l’avenir
      Ce serait sans doute utile de l’ajouter au commentaire original
      Voir le GitHub de fracturedjson-rs et le package crates.io pour plus de détails
      Le commentaire explicatif correspondant est ici
    • C’est une bonne idée, mais je pense qu’il est difficile d’aller au-delà des cas de test jusqu’à une garantie d’équivalence des programmes
    • C’est presque une fonction pure, donc il est très facile d’écrire un harnais de test
    • Les tests pilotés par les données sont très efficaces pour instaurer la confiance dans une bibliothèque
      html5lib-tests ou xss-bench, que j’ai créé, en sont de bons exemples

  • J’ai créé une version portée en Rust, avec un outil CLI permettant de formater du JSON dans ce style
    Installation possible via fracturedjson-rs et le package crates.io (cargo install fracturedjson)
    Il propose diverses options et permet un contrôle fin du style de commentaires, du style d’indentation ou encore de la largeur maximale des lignes

    • La version portée est elle aussi une œuvre dérivée, elle doit donc conserver la mention de copyright de l’auteur original

  • Ce projet est vraiment génial
    J’aime bien cette approche qui rend le JSON plus facile à lire pour les humains
    De mon côté, je développe bonjson, qui prend l’approche inverse et rend le JSON plus adapté aux machines
    Il a exactement les mêmes capacités et contraintes que JSON, tout en étant 35 fois plus rapide en lecture et en écriture
    Il n’ajoute ni nouveaux types ni nouvelles fonctionnalités, il fait simplement exactement ce que JSON peut faire

    • JSON est une notation simple, donc je pense qu’il lui faut un modèle de données formel
      Par exemple, il ne précise pas la largeur en bits des nombres ni la distinction entre entiers et nombres à virgule flottante
      Avec un tel modèle, on pourrait obtenir une correspondance 1:1 entre les représentations
      J’écris à ce sujet cet article
    • C’est intéressant, mais compte tenu de l’affirmation « il peut tout faire comme JSON », les restrictions de sécurité sont un peu surprenantes
      Par exemple, une chaîne comme "a\u0000b" est un JSON valide, donc si elle ne peut pas être sérialisée, cette affirmation n’est pas entièrement vraie
    • Je me demande ce qui t’a amené à créer ça
      J’ai déjà fait un sérialiseur capable de sauvegarder/charger du JSON et des fichiers binaires via une interface commune
      D’après mon expérience, JSON était un format très limité et peu avantageux
      Je l’ai donc remplacé par un format plus permissif qui permet d’omettre les virgules, les deux-points et les guillemets, et qui accepte les chaînes multilignes ainsi que les commentaires
      Il serait temps d’arrêter de prétendre que JSON est toujours un format « lisible par les humains »
      Il faudrait une alternative standard pour les environnements non centrés sur JSON
    • Ça me fait penser à Lite3, posté récemment
    • Je me demande ce que ça donne en taux de compression

  • Surprenant
    J’ai moi aussi implémenté quelque chose de similaire en Python en environ 200 lignes, mais je ne savais pas qu’une telle bibliothèque existait déjà

  • Je me demande s’il existe une option pour accepter une entrée via pipe, comme jq

    • En regardant le code CLI C# dans le dépôt, on peut spécifier l’entrée/sortie standard ou des fichiers
      La version JavaScript et le wrapper Python fournissent le même outil CLI
    • RCL fait du pretty-print par défaut
      rcl e affiche au format RCL, et rcl je produit du JSON
      Il n’aligne pas en tableau comme FracturedJson, mais il effectue des retours à la ligne automatiques selon la largeur, en s’appuyant sur l’algorithme A Prettier Printer de Philip Wadler
    • On peut aussi traiter ça en créant un fichier temporaire avec une substitution de processus <()
    • Dans la plupart des cas, il suffit d’indiquer - comme nom du fichier d’entrée pour lire depuis stdin

  • J’ai créé un formateur JSON appelé Virtuous, et en voyant ça, j’ai presque envie d’abandonner le mien tant c’est impressionnant
    C’est vraiment un travail remarquable

  • J’ai créé un script Groovy appelé « mommyjson »
    Au lieu de préserver le formatage JSON, il affiche sur une seule ligne les relations de parenté de chaque élément (index de tableau, nom d’objet, etc.), ce qui permet de repérer intuitivement la position des données
    Voir le code
    Comme Groovy n’est pas populaire, j’aimerais bien qu’un portage Python voie le jour

    • Bonne idée ! Le fait qu’il existe plusieurs outils de ce genre montre bien que c’est une fonctionnalité dont les gens ont réellement besoin
      Parmi les exemples connus, il y a gron et jstream, que j’ai créé
      Ce serait plus facile à comprendre si tu ajoutais un exemple de sortie
    • Je me demande s’il y a un exemple de sortie

  • Je me demande si JSON est vraiment un format qui a besoin d’être amélioré pour être plus lisible par les humains
    Il existe bien de meilleures façons de présenter des données à l’utilisateur, et je pense que JSON est avant tout fait pour le transport de données entre systèmes

    • En général, on utilise ce genre d’outils lorsqu’on n’a ni schéma clair ni outil de visualisation
      C’est utile en débogage quand il faut comprendre rapidement des données imbriquées complexes
      Cela arrive particulièrement souvent lorsqu’on travaille sur du code d’intégration avec des systèmes externes
    • Moi aussi, j’utilise souvent jq ou python -m json.tool pour lire des données JSON
      Si un outil permet de les afficher encore mieux, il a tout à fait sa valeur
    • Si on abandonne l’aspect lisible par les humains, JSON devient un encodage inefficace
      Au fond, l’intérêt de JSON est qu’il est lisible à la fois par les humains et par les machines, donc pour le débogage, cela reste pertinent

  • J’aime vraiment beaucoup cette idée
    Si l’adoption est lente aujourd’hui, c’est surtout à cause du manque de support dans la plupart des langages et chez les gestionnaires de paquets (homebrew, etc.)
    Compiler la bibliothèque .NET en bibliothèque partagée compatible C permettrait de l’utiliser facilement depuis de nombreux langages

  • Approche intéressante
    Ce serait bien que les formateurs de code fonctionnent aussi comme ça
    Les formateurs actuels sont trop rigides, ce qui rend la structure difficile à percevoir

    • J’ai créé un formateur C++ qui n’utilise que deux types d’objets : des tableaux alignés par tabulations et des blocs sur une seule ligne
      Les commentaires sont alignés à droite pour rester bien nets
      Grâce à cette structure, on peut aussi aligner facilement en 2D des blocs switch-case ou des tableaux de macros
      J’ai codé la couche de base en une heure, et je conçois maintenant un système qui détecte automatiquement les blocs en combinant LSP et observation du code
    • Il m’est déjà arrivé de créer moi-même un formateur XML pour lui donner un aspect tabulaire
      Idéalement, il aurait fallu abandonner XML, mais les contraintes legacy ne le permettaient pas