New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

util: implement %o as formatting specifier #14558

Closed
wants to merge 5 commits into
base: master
from

Conversation

@gla5001
Contributor

gla5001 commented Jul 31, 2017

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

util: implement %o as formatting specifier
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
@vsemozhetbyt

This comment has been minimized.

Show comment
Hide comment
@vsemozhetbyt

This comment has been minimized.

Show comment
Hide comment
@vsemozhetbyt

vsemozhetbyt Aug 1, 2017

Member

One ubuntu1604-arm64 failure in the CI seems unrelated.

@gla5001 Thank you for your contribution!

Member

vsemozhetbyt commented Aug 1, 2017

One ubuntu1604-arm64 failure in the CI seems unrelated.

@gla5001 Thank you for your contribution!

@cjihrig

cjihrig approved these changes Aug 1, 2017

@Trott

This comment has been minimized.

Show comment
Hide comment
@Trott
Member

Trott commented Aug 1, 2017

@tniessen tniessen self-assigned this Aug 1, 2017

@jasnell

jasnell approved these changes Aug 1, 2017

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Aug 1, 2017

Member

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

Member

jasnell commented Aug 1, 2017

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

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 1, 2017

Contributor

Yup. Overlooked that. I'll update docs

Contributor

gla5001 commented Aug 1, 2017

Yup. Overlooked that. I'll update docs

@silverwind

LGTM, except one nit.

Show outdated Hide outdated doc/api/util.md
@hiroppy

hiroppy approved these changes Aug 1, 2017

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 1, 2017

Member

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...

Member

refack commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 1, 2017

Member

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

Member

refack commented Aug 1, 2017

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

@silverwind

This comment has been minimized.

Show comment
Hide comment
@silverwind

silverwind Aug 1, 2017

Contributor

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.

Contributor

silverwind commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 1, 2017

Contributor

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
Contributor

gla5001 commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 1, 2017

Member

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)

Member

refack commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 1, 2017

Member

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.

Member

Fishrock123 commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 1, 2017

Member

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.

Member

Fishrock123 commented Aug 1, 2017

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.

util: implement %o as formatting specifier.
Nit fix and changing behavior of %o
@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 1, 2017

Contributor

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?

Contributor

gla5001 commented Aug 1, 2017

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?

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 1, 2017

Member

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
image
Nither does FF 54
image

Member

refack commented Aug 1, 2017

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
image
Nither does FF 54
image

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 1, 2017

Member

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})

Member

refack commented Aug 1, 2017

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})

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 1, 2017

Contributor

I like that @refack. I'll wait a little for a consensus before implementing it.

Contributor

gla5001 commented Aug 1, 2017

I like that @refack. I'll wait a little for a consensus before implementing it.

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 2, 2017

Member

I'd be against implementing anything additional that is not in the console standard. %j is not in the spec, but already in Node.js so whatever. %J is not, and I'll be against adding it.

@refack I believe @Fishrock123 is saying keeping this PR as is, which is what I'm advocating as well. I honestly don't see the reason why JSON is any better than util.inspect, especially for the case where the object has a circular reference to itself. util.format should not throw for any basic objects (excluding wacky ones with proxy).

Member

TimothyGu commented Aug 2, 2017

I'd be against implementing anything additional that is not in the console standard. %j is not in the spec, but already in Node.js so whatever. %J is not, and I'll be against adding it.

@refack I believe @Fishrock123 is saying keeping this PR as is, which is what I'm advocating as well. I honestly don't see the reason why JSON is any better than util.inspect, especially for the case where the object has a circular reference to itself. util.format should not throw for any basic objects (excluding wacky ones with proxy).

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 2, 2017

Member

I honestly don't see the reason why JSON is any better than util.inspect, especially for the case where the object has a circular reference to itself. util.format should not throw for any basic objects (excluding wacky ones with proxy).

My only intuition is to use the two options %o and %O to get two new formats, and not have both output the same thing. What exactly, I have no strong opinion. Although if we nix %J than my preference is for:
%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})

Member

refack commented Aug 2, 2017

I honestly don't see the reason why JSON is any better than util.inspect, especially for the case where the object has a circular reference to itself. util.format should not throw for any basic objects (excluding wacky ones with proxy).

My only intuition is to use the two options %o and %O to get two new formats, and not have both output the same thing. What exactly, I have no strong opinion. Although if we nix %J than my preference is for:
%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 2, 2017

Contributor

So is it safe to say we have a consensus on this to not JSON stringify and just inspect the object. Outputting 2 different formats, depending on specifier used.

%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})
Contributor

gla5001 commented Aug 2, 2017

So is it safe to say we have a consensus on this to not JSON stringify and just inspect the object. Outputting 2 different formats, depending on specifier used.

%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})
@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 2, 2017

Member
%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})

This seems like a good suggestion to me, although I think we should refine the %o options a bit.
(See util.inspect() options)

My recommendation would be something like this, maybe depth: 3 instead:

{ showHidden: true, depth: 4, showProxy: true }
Member

Fishrock123 commented Aug 2, 2017

%O - util.inspect(obj)
%o - util.inspect(obj, {showHidden: true, breakLength:10})

This seems like a good suggestion to me, although I think we should refine the %o options a bit.
(See util.inspect() options)

My recommendation would be something like this, maybe depth: 3 instead:

{ showHidden: true, depth: 4, showProxy: true }
@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 2, 2017

Member

My only intuition is to use the two options %o and %O to get two new formats

Maybe, but thats not how the spec defines these formatters. As I've pointed out in #14545 (comment), the two specifiers are spec'd to parallel console.log() and console.dir(). If the specifiers are to be made different, well, console.log() and/or console.dir() should be changed first.

Member

TimothyGu commented Aug 2, 2017

My only intuition is to use the two options %o and %O to get two new formats

Maybe, but thats not how the spec defines these formatters. As I've pointed out in #14545 (comment), the two specifiers are spec'd to parallel console.log() and console.dir(). If the specifiers are to be made different, well, console.log() and/or console.dir() should be changed first.

@Fishrock123

This comment has been minimized.

Show comment
Hide comment
@Fishrock123

Fishrock123 Aug 2, 2017

Member

Hmmmm, true. I think that would be useful but maybe we should have that change be separate.

(@gla5001 sorry for all the back-and-forth, some things need discussion to nail down well. 😄)

Member

Fishrock123 commented Aug 2, 2017

Hmmmm, true. I think that would be useful but maybe we should have that change be separate.

(@gla5001 sorry for all the back-and-forth, some things need discussion to nail down well. 😄)

@silverwind

This comment has been minimized.

Show comment
Hide comment
@silverwind

silverwind Aug 2, 2017

Contributor

@TimothyGu I don't quite read your analogy of %o being like console.dir and %O being like console.log out of the spec. For the specifiers it says:

If specifier is %o, optionally let converted be current with optimally useful formatting applied.
If specifier is %O, optionally let converted be current with generic JavaScript object formatting applied.

And for log/dir:

2.1.7. log(...data) (no specifics on formatting)
2.1.11. dir(item, options): Let object be item with generic JavaScript object formatting applied.

So the term generic JavaScript object formatting is applied to %O and dir. Possible spec bug?

Contributor

silverwind commented Aug 2, 2017

@TimothyGu I don't quite read your analogy of %o being like console.dir and %O being like console.log out of the spec. For the specifiers it says:

If specifier is %o, optionally let converted be current with optimally useful formatting applied.
If specifier is %O, optionally let converted be current with generic JavaScript object formatting applied.

And for log/dir:

2.1.7. log(...data) (no specifics on formatting)
2.1.11. dir(item, options): Let object be item with generic JavaScript object formatting applied.

So the term generic JavaScript object formatting is applied to %O and dir. Possible spec bug?

@silverwind

This comment has been minimized.

Show comment
Hide comment
@silverwind

silverwind Aug 2, 2017

Contributor

Regarding the "nicer" formatting, I think we might want a new indent option on util.inspect for it that works like JSON.stringify's third argument. Using JSON.stringify is out of question for me, because JSON cannot represent many types.

Contributor

silverwind commented Aug 2, 2017

Regarding the "nicer" formatting, I think we might want a new indent option on util.inspect for it that works like JSON.stringify's third argument. Using JSON.stringify is out of question for me, because JSON cannot represent many types.

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 2, 2017

Contributor

@Fishrock123 its no worries. Better to get it nailed down correctly.

Contributor

gla5001 commented Aug 2, 2017

@Fishrock123 its no worries. Better to get it nailed down correctly.

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 2, 2017

Contributor

Maybe i jumped the gun on the most recent commit, but it seemed like the direction the conversation was going.

Contributor

gla5001 commented Aug 2, 2017

Maybe i jumped the gun on the most recent commit, but it seemed like the direction the conversation was going.

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Aug 2, 2017

@refack we did change some things in our console recently. I just discussed the array case you screenshotted, and we consider that a bug. It should show the inline/preview representation of the array.

FWIW the 4 cases where Chrome DevTools currently shows something different between %o and %o are:

  1. Errors:
  2. Functions:
  3. Arrays: (once we fix the regression):
  4. DOM Elements: (may not apply to node's console, but perhaps it does for electron?)

These are consistent with console.log and console.dir.... Indeed o and O map directly to the exact same formatting logic.

There are other cases where I could imagine slightly different representations, like maps and sets. Or proxies.. However we haven't yet done that in Chrome.

paulirish commented Aug 2, 2017

@refack we did change some things in our console recently. I just discussed the array case you screenshotted, and we consider that a bug. It should show the inline/preview representation of the array.

FWIW the 4 cases where Chrome DevTools currently shows something different between %o and %o are:

  1. Errors:
  2. Functions:
  3. Arrays: (once we fix the regression):
  4. DOM Elements: (may not apply to node's console, but perhaps it does for electron?)

These are consistent with console.log and console.dir.... Indeed o and O map directly to the exact same formatting logic.

There are other cases where I could imagine slightly different representations, like maps and sets. Or proxies.. However we haven't yet done that in Chrome.

@refack

refack approved these changes Aug 2, 2017

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 2, 2017

Member

@gla5001 IMHO current implementation is close to @paulirish's example (except we don't show __proto__), so 👍 from me.

Member

refack commented Aug 2, 2017

@gla5001 IMHO current implementation is close to @paulirish's example (except we don't show __proto__), so 👍 from me.

@TimothyGu

Still LGTM, but would like some answers first before landing.

@@ -167,6 +167,14 @@ corresponding argument. Supported placeholders are:
* `%f` - Floating point value.
* `%j` - JSON. Replaced with the string `'[Circular]'` if the argument
contains circular references.
* `%o` - Object. A string representation of an object
with generic JavaScript object formatting.
Similar to `util.inspect()` with options `{ showHidden: true, depth: 4, showProxy: true }`.

This comment has been minimized.

@TimothyGu

TimothyGu Aug 3, 2017

Member

What's the default for depth? I think we shouldn't change its default.

I'm okay with showProxy, but some people may interpret it as violating a security contract (where Proxies are supposed to be transparent)…

@TimothyGu

TimothyGu Aug 3, 2017

Member

What's the default for depth? I think we shouldn't change its default.

I'm okay with showProxy, but some people may interpret it as violating a security contract (where Proxies are supposed to be transparent)…

This comment has been minimized.

This comment has been minimized.

@TimothyGu

TimothyGu Aug 3, 2017

Member

So what was the rationale for using 4 instead?

@TimothyGu

TimothyGu Aug 3, 2017

Member

So what was the rationale for using 4 instead?

This comment has been minimized.

@refack

refack Aug 3, 2017

Member

Even though I didn't originate it, IMHO it comes from optimally useful formatting and 2 is too small.
Since we can't do interactive expansion like in a GUI, Ideally I'd say it needs to be Infinity, but that's unreasonable.

This does make me think about a configurable util.inspect.extendedFormattingOptions or even util.format.optimallyUsefulFormatter but that could happen in a later PR.

@refack

refack Aug 3, 2017

Member

Even though I didn't originate it, IMHO it comes from optimally useful formatting and 2 is too small.
Since we can't do interactive expansion like in a GUI, Ideally I'd say it needs to be Infinity, but that's unreasonable.

This does make me think about a configurable util.inspect.extendedFormattingOptions or even util.format.optimallyUsefulFormatter but that could happen in a later PR.

This comment has been minimized.

@refack

refack Aug 3, 2017

Member

Just for fun, I took a stroll down memory lane:
This is where is where depth was introduced a2714be
Two hour later the defaults were set de15214
Values seem to be a personal preferance https://groups.google.com/d/msg/nodejs/rAYFIeJ_72U/_bWLezvZavEJ

@refack

refack Aug 3, 2017

Member

Just for fun, I took a stroll down memory lane:
This is where is where depth was introduced a2714be
Two hour later the defaults were set de15214
Values seem to be a personal preferance https://groups.google.com/d/msg/nodejs/rAYFIeJ_72U/_bWLezvZavEJ

This comment has been minimized.

@silverwind

silverwind Aug 3, 2017

Contributor

How about just using null?

@silverwind

silverwind Aug 3, 2017

Contributor

How about just using null?

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 3, 2017

Member

Also would like a pre-ruling on this - will adding real indenting to util.inspect and turning it on for %o later (but hopefully before this goes public) be semver-major?

Member

refack commented Aug 3, 2017

Also would like a pre-ruling on this - will adding real indenting to util.inspect and turning it on for %o later (but hopefully before this goes public) be semver-major?

@TimothyGu

This comment has been minimized.

Show comment
Hide comment
@TimothyGu

TimothyGu Aug 3, 2017

Member

@refack What kind of "real indenting" are you thinking? I don't think it would be semver-major to change inspection output.

Member

TimothyGu commented Aug 3, 2017

@refack What kind of "real indenting" are you thinking? I don't think it would be semver-major to change inspection output.

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 3, 2017

Member

@refack What kind of "real indenting" are you thinking? I don't think it would be semver-major to change inspection output.

Braces and brackets on new lines, a la JSON.stringify:

> const o = {a:1, b:2, c:3, d:4, e: [1,2,3,4]}
undefined
> console.log(JSON.stringify(o, null, 2))
{
  "a": 1,
  "b": 2,
  "c": 3,
  "d": 4,
  "e": [
    1,
    2,
    3,
    4
  ]
}
undefined

// only half way there
> console.log(util.inspect(o, {breakLength: 4}))
{ a: 1,
  b: 2,
  c: 3,
  d: 4,
  e:
   [ 1,
     2,
     3,
     4 ] }
Member

refack commented Aug 3, 2017

@refack What kind of "real indenting" are you thinking? I don't think it would be semver-major to change inspection output.

Braces and brackets on new lines, a la JSON.stringify:

> const o = {a:1, b:2, c:3, d:4, e: [1,2,3,4]}
undefined
> console.log(JSON.stringify(o, null, 2))
{
  "a": 1,
  "b": 2,
  "c": 3,
  "d": 4,
  "e": [
    1,
    2,
    3,
    4
  ]
}
undefined

// only half way there
> console.log(util.inspect(o, {breakLength: 4}))
{ a: 1,
  b: 2,
  c: 3,
  d: 4,
  e:
   [ 1,
     2,
     3,
     4 ] }
@tniessen

This comment has been minimized.

Show comment
Hide comment
Member

tniessen commented Aug 4, 2017

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen Aug 4, 2017

Member

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

Member

tniessen commented Aug 4, 2017

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

@tniessen tniessen closed this Aug 4, 2017

tniessen added a commit that referenced this pull request Aug 4, 2017

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

PR-URL: #14558
Fixes: #14545
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 4, 2017

Contributor

awesome. thanks!

Contributor

gla5001 commented Aug 4, 2017

awesome. thanks!

@tniessen

This comment has been minimized.

Show comment
Hide comment
@tniessen

tniessen Aug 4, 2017

Member

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!

Member

tniessen commented Aug 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 4, 2017

Member

@gla5001 congrats on GitHub promoting you from:
image
to
image
🍾

Member

refack commented Aug 4, 2017

@gla5001 congrats on GitHub promoting you from:
image
to
image
🍾

@refack

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 4, 2017

Member

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

Member

refack commented Aug 4, 2017

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

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 4, 2017

Contributor

@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?

Contributor

gla5001 commented Aug 4, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 4, 2017

Member

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

No issue just my comment above #14558 (comment)

Member

refack commented Aug 4, 2017

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

No issue just my comment above #14558 (comment)

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Aug 4, 2017

Member

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.

Member

domenic commented Aug 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@refack

refack Aug 4, 2017

Member

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

Member

refack commented Aug 4, 2017

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

@gla5001

This comment has been minimized.

Show comment
Hide comment
@gla5001

gla5001 Aug 5, 2017

Contributor

Starting discussion #14638

Contributor

gla5001 commented Aug 5, 2017

Starting discussion #14638

addaleax added a commit that referenced this pull request Aug 10, 2017

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

PR-URL: #14558
Fixes: #14545
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Evan Lucas <evanlucas@me.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>

addaleax added a commit to addaleax/node that referenced this pull request Aug 13, 2017

addaleax added a commit that referenced this pull request Aug 13, 2017

doc: add missing `changes:` metadata for util
Ref: #14558
PR-URL: #14810
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

addaleax added a commit that referenced this pull request Aug 13, 2017

doc: add missing `changes:` metadata for util
Ref: #14558
PR-URL: #14810
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>

addaleax added a commit that referenced this pull request Aug 13, 2017

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](#8837)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for readable the readable and the writable side.
    [#14636](#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](#14558)

@addaleax addaleax referenced this pull request Aug 13, 2017

Merged

v8.4.0 proposal #14811

addaleax added a commit that referenced this pull request Aug 13, 2017

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](#8837)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](#14558)

PR-URL: #14811

addaleax added a commit that referenced this pull request Aug 14, 2017

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **HTTP2**
  * Experimental support for the built-in `http2` has been added via the
    `--expose-http2` flag.
    [#14239](#14239)

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](#8837)
  * Multiple contexts, as created by the `vm` module, are supported now.
    [#14465](#14465)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](#14558)

PR-URL: #14811

evanlucas added a commit that referenced this pull request Aug 15, 2017

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **HTTP2**
  * Experimental support for the built-in `http2` has been added via the
    `--expose-http2` flag.
    [#14239](#14239)

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](#8837)
  * Multiple contexts, as created by the `vm` module, are supported now.
    [#14465](#14465)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](#14558)

PR-URL: #14811

MSLaguana added a commit to nodejs/node-chakracore that referenced this pull request Aug 21, 2017

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **HTTP2**
  * Experimental support for the built-in `http2` has been added via the
    `--expose-http2` flag.
    [#14239](nodejs/node#14239)

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](nodejs/node#8837)
  * Multiple contexts, as created by the `vm` module, are supported now.
    [#14465](nodejs/node#14465)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](nodejs/node#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](nodejs/node#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](nodejs/node#14558)

PR-URL: nodejs/node#14811

@pvdlg pvdlg referenced this pull request Oct 30, 2017

Closed

fix: Update npx command line #496

@gibfahn

This comment has been minimized.

Show comment
Hide comment
@gibfahn

gibfahn Jan 15, 2018

Member

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

Member

gibfahn commented Jan 15, 2018

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

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 12, 2018

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **HTTP2**
  * Experimental support for the built-in `http2` has been added via the
    `--expose-http2` flag.
    [#14239](nodejs#14239)

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](nodejs#8837)
  * Multiple contexts, as created by the `vm` module, are supported now.
    [#14465](nodejs#14465)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](nodejs#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](nodejs#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](nodejs#14558)

This applies parts of 1fe0741 that are
relevant to N-API.

PR-URL: nodejs#14811

gabrielschulhof added a commit to gabrielschulhof/node that referenced this pull request Mar 15, 2018

2017-08-15, Version 8.4.0 (Current)
Notable changes

* **HTTP2**
  * Experimental support for the built-in `http2` has been added via the
    `--expose-http2` flag.
    [#14239](nodejs#14239)

* **Inspector**
  * `require()` is available in the inspector console now.
    [#8837](nodejs#8837)
  * Multiple contexts, as created by the `vm` module, are supported now.
    [#14465](nodejs#14465)

* **N-API**
  * New APIs for creating number values have been introduced.
    [#14573](nodejs#14573)

* **Stream**
  * For `Duplex` streams, the high water mark option can now be set
    independently for the readable and the writable side.
    [#14636](nodejs#14636)

* **Util**
  * `util.format` now supports the `%o` and `%O` specifiers for printing
    objects.
    [#14558](nodejs#14558)

This applies parts of 1fe0741 that are
relevant to N-API.

PR-URL: nodejs#14811
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment