There's an older pure Python version but it's no longer maintained - the author of that recently replaced it with a Python library wrapping the C# code.

This looks to me like the perfect opportunity for a language-independent conformance suite - a set of tests defined as data files that can be shared across multiple implementations.

This would not only guarantee that the existing C# and TypeScript implementations behaved exactly the same way, but would also make it much easier to build and then maintain more implementations across other languages.

Interestingly the now-deprecated Python library does actually use a data-driven test suite in the kind of shape I'm describing: https://github.com/masaccio/compact-json/tree/main/tests/dat...

That new Python library is https://pypi.org/project/fractured-json/ but it's a wrapper around the C# library and says "You must install a valid .NET runtime" - that makes it mostly a non-starter as a dependency for other Python projects because it breaks the ability to "pip install" them without a significant extra step.

https://github.com/fcoury/fracturedjson-rs

https://crates.io/crates/fracturedjson

And install with:

cargo install fracturedjson

    > $ fjson --help
    Rust port of FracturedJsonJs: human-friendly JSON formatter with optional comment support.

    Usage: fjson [OPTIONS] [FILE]...

    Arguments:
      [FILE]...  Input file(s). If not specified, reads from stdin

    Options:
      -o, --output <FILE>
              Output file. If not specified, writes to stdout
      -c, --compact
              Minify output (remove all whitespace)
      -w, --max-width <MAX_WIDTH>
              Maximum line length before wrapping [default: 120]
      -i, --indent <INDENT>
              Number of spaces per indentation level [default: 4]
      -t, --tabs
              Use tabs instead of spaces for indentation
          --eol <EOL>
              Line ending style [default: lf] [possible values: lf, crlf]
          --comments <COMMENTS>
              How to handle comments in input [default: error] [possible values: error, remove, preserve]
          --trailing-commas
              Allow trailing commas in input
          --preserve-blanks
              Preserve blank lines from input
          --number-align <NUMBER_ALIGN>
              Number alignment style in arrays [default: decimal] [possible values: left, right, decimal, normalize]
          --max-inline-complexity <MAX_INLINE_COMPLEXITY>
              Maximum nesting depth for inline formatting (-1 to disable) [default: 2]
          --max-table-complexity <MAX_TABLE_COMPLEXITY>
              Maximum nesting depth for table formatting (-1 to disable) [default: 2]
          --simple-bracket-padding
              Add padding inside brackets for simple arrays/objects
          --no-nested-bracket-padding
              Disable padding inside brackets for nested arrays/objects
      -h, --help
              Print help
      -V, --version
              Print version

I've also been working in the other direction, making JSON more machine-readable:

https://github.com/kstenerud/bonjson/

It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write.

No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can't do.

And BTW, thanks for supporting comments - the reason given for keeping comments out of standard Json is silly ( "they would be used for parsing directives" ).

I can see potential usefulness of this is in debug mode APIs, where somehow comments are sent as well and are rendered nicely. Especially useful in game dev jsons.

https://github.com/zaboople/bin/blob/master/mommyjson.groovy

(btw I would happily upvote a python port, since groovy is not so popular)

What I like about fractured json is the middle ground between too-sparse pretty printing, and too-compact non-pretty printing, nu doesn't give me that by default.

One thing that neither fractured json nor nushell gives me, which I'd like, is the ability to associate an annotation with a particular datum, convert to json, convert back to the first language, and have that comment still be attached to that datum. Of course the intermediate json would need to have some extra fields to carry the annotations, which would be fine.

But then I found it's in C#. And apparently the CLI app isn't even published any more (apparently nobody wanted it? Surprises me but ok). Anyway, I don't think I want this enough to install .NET to get it, so that's that. But I'd have liked a version in Go or Rust or whatever.

That way, the original JSON file stays clean and isn’t polluted with extra data.

this tool also looks super useful, I spend so much time at work looking at json logs that this will surely come in handy. It’s the kind of thing I didn’t even know I needed, but now that I saw it it makes perfect sense.

It should even be possible to compile the dotnet library to a C-compatible shared library and provide packages for many other languages.

  {
    foo: "bar",
    ans: 42,
    comments: {
      ans: "Douglas Adams"
    }
  }

Though, I guess, the only(?) great XML workflow is with C# LINQ

Personally, I don't spend much time looking at complex JSON; a binary format like Protobuf along with a typed DSL is often what you need. You can still derive JSON from Proto if you need that. In return, you get faster transport and type safety.

Also, on another note, tools like jq are so ubiquitous that any format that isn't directly supported by jq will have a really hard time seeing mass adoption.

I know that LLMs are very familiar with JSON, and choosing uncommon schemas just to reduce tokens hurts semantic performance. But a schema that is sufficiently JSON-like probably won't disrupt model path/patterns that much and prevent unintended bias.