New Rule: Format JSON files as JSON.stringify(x, null, 2) would

[kemitchell]

I'd be interested in adding a rule to standard that checks the formatting of JSON files. In particular, I'd like to add a rule that checks that JSON files have been formatted with JSON.stringify(x, null, 2).

The most important "target" for the rule will often be package.json. Consistency there would help reduce diff size and awkward patches. I believe npm@5 recently added autodetection of indentation in package.json for much the same reason, as npm install --save and similar could change indentation in prior versions.

The rule would also apply to other JSON files in the working tree. Often, these files are treated exactly like source code, brought in with require('./somefile.json').

The JSON.stringify algorithm is very straightforward and predictable. I believe it is also mostly consistent with standard's rules for object literals, like a single space after comma.

Other JSON formatting algorithms arguably do better in terms of readability. I wrote one, aping LISP style that puts a great deal more data on screen at a time. Others have implemented ML-esque, comma-first style, which trades readability for minimal diffs.

I've always ended up going back to JSON.stringify. It's built into the language. It's intuitive enough that folks can match its output manually if they have to. It strikes a decent compromise between readability and minimal diff. It is, for all those reasons, the de facto "standard". It's also dead simple to "fix" JSON formatted otherwise automatically.

Some maintainers might like to go further, and enforce something like json-stable-stringify, which sorts keys. I'd be tempted to do that in some of my own projects, but it doesn't feel "standard". Moreover, where I'd want that kind of hard consistency, I'd probably also want array sorting and other changes that affect semantics, not just syntax.

[Flet]

Formatting JSON files is an interesting idea!

Currently standard is a curated set of eslint rules, so its capabilities are tied to rules that are exposed via eslint (or rules we've built in custom plugins). standard also is hard coded to scan only JS and JSX files currently.

I'm not sure if eslint supports parsing JSON files, and I don't see any built-in rules around JSON in eslint's documentation. These would be significant challenges to overcome to get this to work.

I think a separate formatting tool might make sense! I don't know if it makes sense to build this into standard at the moment.

[kemitchell]

@Flet, is this really something I should propose for eslint?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.