util: inspect prototype properties if showHidden is truthy
#30768
Conversation
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed.
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Fixes: nodejs#30183
BridgeAR
added
the
semver-major
nodejs-github-bot
added
the
util
Originally I intended to filter those but I changed my mind while implementing the feature due to only inspecting user defined prototypes, not built-in ones. We do print all other functions while inspecting and this seemed more consistent. I personally would like to know all user defined methods when using @nodejs/util PTAL and vote to get some further opinions: ❤️ filter prototype methods |
Isn’t that even worse, special-casing built-ins? |
We already inspect some built-in prototype properties when using It would also mean a significant performance hit to inspect all prototypes and not only user defined ones. This implementation is quite cheap though and solves the feature request that I referenced. |
|
@BridgeAR Right, I agree with everything you said – but what makes built-ins special? Doesn’t this feature get in the way for any larger classes, user-defined or not? |
Users mostly know about built-in prototype properties (no matter if it's a method or another value) but they rarely know about user defined ones. Especially not, if it's not written by themselves.
Using I guess one way forward would be to allow a more fine-grained option. That way it's possible for the user to explicitly define what should be inspected: showHidden: {
prototypes: Boolean // Or even more fine grained as in: ['user', 'all', 'builtIn']
weakEntries: Boolean,
nonEnumerable: Boolean
} |
|
@addaleax I decided to skip inspecting the methods for now. I might add more granular configuration later on where it's also possible to inspect methods. PTAL. |
This comment has been minimized.
This comment has been minimized.
Co-Authored-By: Michaël Zasso <targos@protonmail.com>
Co-Authored-By: Michaël Zasso <targos@protonmail.com>
This comment has been minimized.
This comment has been minimized.
targos
added
semver-minor
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@BridgeAR Removed my review here |
|
CI: https://ci.nodejs.org/job/node-test-pull-request/27627/ ✅ (yellow build with two frequent windows flakes) |
BridgeAR
added
the
author ready
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
targos
added
baking-for-lts
This makes sure that the regular expression matches all built-in objects properly. So far a couple where missed. PR-URL: nodejs#30768 Fixes: nodejs#30183 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: nodejs#30768
Fixes: nodejs#30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Backport-PR-URL: #31431
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
MylesBorins
added
backported-to-v12.x
and removed
backport-open-v12.x
baking-for-lts
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
Backport-PR-URL: #31431
PR-URL: #30768
Fixes: #30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Please have a look at the commit messages for details.
I marked this as semver-major. We might also handle it as semver-minor instead but I wanted to be on the safe side. Please weight in case someone would like this to change.
I tried hard to implement this with the least performance overhead possible and I believe this is pretty much it.
Fixes: #30183
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes