Add %J console format specifier

[wltsmrz]

This pull request adds %J format specifier for printing indented JSON.

I believe there may be some appetite for achieving this without cumbersome console.log(JSON.stringify(a, null, 2)). Some representative github code searches:

• "console.log(" "JSON.stringify(" 3.5mil JS results
• "console.log(" "%j" 1.1mil JS results
• "console.dir(" 300k JS results

Actually, now that I look at previous github issues this exact idea was mentioned in #14558. The controversial %o format specifier does seem to be getting a lot of use, as far as I can tell with github code search. Thoughts?

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[BridgeAR]

%J is not in the spec (and neither is %j). I would rather not add more specifiers that are not included in the spec. If that would happen first, that would be totally fine to me. Right now I am -0 on this change.

The main question for me in this case where JSON.stringify(object, null, 2) would be preferred over util.inspect(object). JSON is not able to print things as detailed and will even skip some data.

The controversial %o format

It is new to me that it's controversial. Do you have a source where this is discussed? I saw the comments in the referenced issue but it did not seem really controversial to me?

[wltsmrz]

Worth a try! I'm not going to argue this one much as the reasons for including %J are obvious, as are the reasons for not including it (not in the spec, bloat-prevention).

I believe that console.log('%J', a) would be preferred to console.log(JSON.stringify(a, b, c)), and that this is a quite common interest according to github search. Given the non-indented formatter %j is already in the codebase (albeit begrudgingly perhaps), it seems reasonable to me.

[devsnek]

we should only implement standardized specifiers

[himself65]

we should only implement standardized specifiers

+1

[addaleax]

I’ll close this, given that consensus appears to be that we should not add non-standard specifiers. Thanks for the pull request, though!