As I mentioned in the #20 review, in-json was not meant to be a raw expected result string (that would be called out-json), but rather a loaded JSON input that would be compared either in memory or by a reserialization into any mature/trusted format.

That said, I support the change if it helps people use the data in other useful ways and does not break any existing testing.

• Why should this change break any existing testing? I will let the test matrix run before merging it to master
• if we generate in.json half-automatically, a canonical format will guarantee that we only get diffs for real changes

With the changes brought in by PR #20, the in.json files representing streams with multiple documents can no longer be easily parsed in a JS environment. In fact jq might be one of the only tools that can parse their format without complaint.

As is, the files are pretty close to line-delimited JSON, for which tools do exist. Therefore, would it be possible to add a step that would use something like jq -c in their generation?

I encountered this problem while updating the tests of my JS YAML library, which can in fact read the in.json format, but complains about it:

import fs from 'fs'
import YAML from 'yaml'
const src = fs.readFileSync('./U9NS/in.json', 'utf8')
const doc = YAML.parseDocuments(src)[0]

doc.errors
// [ [YAMLSyntaxError: Document is not valid YAML (bad indentation?)] ]

doc.contents[0].toJSON()
// { time: '20:03:20',
//   player: 'Sammy Sosa',
//   action: 'strike (miss)' }

doc.contents[1].toJSON()
// { time: '20:03:47',
//   player: 'Sammy Sosa',
//   action: 'grand slam' }