Repository navigation
console.log(proxy) default output is less than helpful #60964
Description
Version
All
Platform
All
Subsystem
console/util.inspect
What steps will reproduce the bug?
const p = new Proxy({}, {
ownKeys() { return ['a']; },
getOwnPropertyDescriptor() {
return { value: 1, writable: false, enumerable: true, configurable: true };
},
has() { return true; },
get() { return 1; },
});
console.log(p); // Outputs '{}'How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
Ideally, the output would include all enumerable properties, just like it would with a normal, non-proxy object.
What do you see instead?
{} ... omitting the enumerable ownKeys
Additional information
No response
Activity
jasnell commentedon Dec 5, 2025
/cc @BridgeAR
benjamingr commentedon Dec 7, 2025
So:
isProxywith the internal API)ObjectKeyson it and format those values like other objects.This would be related to #26241 which made the code stricter and not looser (see #10731 ).
IIRC
util.inspectdoes haveshowProxiesbut that wouldn't work in this case since it'd just show the original object (empty) and the definition/fact there is ownKeys.So - the question is "can we determine if calling the proxy traps is side effect free" - maybe if the proxy is tagged well enough we can check kHasSideEffect and if it's side effect free execute it.
BridgeAR commentedon Dec 8, 2025
This is working as intended so far. We actively do not trigger any proxy traps.
We could in theory add another mode that would trigger all proxy traps that the implementation might use, while they could change over time without any guarantee for what proxy traps would be triggered and when.
I personally do not think we should implement that.
Figuring out if a proxy trap is
side effect freeis also impossible, as far as I can tell and it would not overcome the above issue, as well as potentially being confusing for users to trigger traps in some cases while not in others.jasnell commentedon Dec 8, 2025
That's fine, an understandable. At the very least, it might make sense to add some detail to the output so it's at least more helpful than returning
{}... something like{ [Proxy] }or something that would indicate that there's something unusual with the case would be helpful.BridgeAR commentedon Dec 8, 2025
I checked and Safari, Firefox, and Chrome all show that information by default. So I guess we could indeed show that the object is proxied as well. It does expose some information about it though and I am uncertain if it matches user's expectations in all cases.
Maybe someone else might want to chime in?
targos commentedon Dec 10, 2025
Showing that the object is proxied SGTM. We could also print the names of the proxy traps that are defined.
BridgeAR commentedon Dec 11, 2025
@targos that would effectively result in
showProxyoption being set to true (it only inspects the traps and logs these methods in addition to inspecting the actual object).util: mark proxied objects as such when inspecting them
util: mark proxied objects as such when inspecting them