util: implement %o as formatting specifier

[gla5001]

Implementing the %o and %O as formatting specifier for util.format.
Based on discussion in issue, this specifier should just call
util.inspect to format passed in value.

Fixes: #14545

Checklist

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

Affected core subsystem(s)

util

[vsemozhetbyt]

CI: https://ci.nodejs.org/job/node-test-pull-request/9424/

[vsemozhetbyt]

One ubuntu1604-arm64 failure in the CI seems unrelated.

@gla5001 Thank you for your contribution!

[Trott]

/cc @Fishrock123

[jasnell]

This may possibly also need documentation added (I cannot remember how extensively we've documented the formatting specifiers)

[gla5001]

Yup. Overlooked that. I'll update docs

[silverwind]

LGTM, except one nit.

[silverwind]

Nit: Indent this line

[refack]

Is it too late to consider %o to be JSON.stringify(obj, null, ' ') which is just pretty JSON.
I feel like making %o and %O do the same is a missed opportunity...

[refack]

Or if there's no consensus let's implement just one, since changing it later will be semver-major

[silverwind]

I think it'd make sense to indent %o, it certainly fits the "optimally useful formatting" mentioned in the spec. Maybe with two spaces as that's the most common form of indentation in JS.

[gla5001]

So im happy to implement whatever. Just need a consensus on it.

1. Keep as is
2. Remove the %O and just have %o
3. Change %o to JSON.stringify with 2 spaces

[refack]

Quoting #14545 (comment)

%O

An object with generic JavaScript object formatting is a potentially expandable representation of a generic JavaScript object.

%o

An object with optimally useful formatting is an implementation-specific, potentially-interactive representation of an object judged to be maximally useful and informative.

---

IMHO
%o - JSON.stringify(obj, null, ' ')
%O - util.inspect(obj)

[Fishrock123]

I don't agree with @refack here. I don't think that JSON-ifying is more detailed, rather it is less, as JSON can't represent everything.

[Fishrock123]

Considering browsers differentiate this by using a util.inspect()-like output with variances that are not possible in Node, I think it backs that up.

[gla5001]

Should they be the same then? By JSON-ifying one and inspecting the other, you now the option of displaying more or less detail. Which could be useful in some cases?

[vsemozhetbyt]

It seems we should state explicitly that JSON stringification is involved here with its restrictions.

[gla5001]

@vsemozhetbyt Hows that look?

[vsemozhetbyt]

It seems explicit enough if we do have a consensus for this behavior.

[refack]

I don't agree with @refack here. I don't think that JSON-ifying is more detailed, rather it is less, as JSON can't represent everything.

@Fishrock123 So are you suggesting to reverse may suggestion for %O and %o? I'm fine with that, it's more important to me that have get two more representations. Or are you suggesting not to use JSON.stringify at all?

so tl;dr in terms of "human usefulness" %j < %O < %o ?

> const nestedObj = {
...   foo: 'bar',
...   foobar: {
.....     foo: 'bar',
.....     func: function() {}
.....   }
... };

> console.log("%j", nestedObj)
{"foo":"bar","foobar":{"foo":"bar"}}

> console.log(JSON.stringify(nestedObj, null, '  '))
{
  "foo": "bar",
  "foobar": {
    "foo": "bar"
  }
}

> console.log(util.inspect(nestedObj))
{ foo: 'bar', foobar: { foo: 'bar', func: [Function: func] } }

or go big and

> console.log(util.inspect(nestedObj, {showHidden: true, breakLength:10}))
{ foo: 'bar',
  foobar:
   { foo: 'bar',
     func:
      { [Function: func]
        [length]: 0,
        [name]: 'func',
        [prototype]: [Object] } } }

---

BTW: Chrome 60 has no obvius distinction

Nither does FF 54

[refack]

Another idea ( @gla5001 sorry for the noise ), add %J so:
%j - JSON.stringify(obj)
%J - JSON.stringify(obj, null, ' ')
%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})

[tniessen]

Landed in 211df3f! Thank you for your efforts, great first contribution! 🎉

[gla5001]

awesome. thanks!

[tniessen]

Just a few tips for the future:

• You might want to configure git to warn you about whitespace problems, e.g. trailing whitespace. We fix those problems when landing your changes, but it can make rebasing more difficult. You can also configure some editors to highlight those problems, and depending on your git interface, you might see such problems highlighted in red when reviewing your changes.
• Our commit message guidelines do not apply to fixup commits, so you don't need to repeat the same title throughout all commits within a PR, as long as the first commit has a proper message. While landing PRs, we usually squash your commits, and having the same commit title each time is not helpful. For fixup commits, just describe what you fixed in the commit title. (This does not apply to PRs which consist of multiple independent commits, but most PRs are a single commit and then a lot of fixups.)

We are looking forward to your next contribution!

[refack]

@gla5001 congrats on GitHub promoting you from:

to

🍾

[refack]

P.S. a nice second contribution might be adding an indent option to util.inspect 😉

[gla5001]

@tniessen Thanks! I'll make sure to take those tips into account next time.

@refack Happy to look at that one next. Is there an issue for it?

[refack]

@refack Happy to look at that one next. Is there an issue for it?

No issue just my comment above #14558 (comment)

[domenic]

I would not suggest that as a PR, as I doubt it's something the community is interested in (I personally think it's a bad idea). It would need a dedicated issue with discussion and appropriate input from decider-people.

[refack]

Well @gla5001 opening an issue and discussing a new feature is also a nice contribution.

[gla5001]

Starting discussion #14638

[gibfahn]

Release team were +1 on backporting to v6.x.