util: mark proxied objects as such when inspecting them

[BridgeAR]

Fixes: #60964

[addaleax]

Seems fine, but should this be semver-major out of an abundance of caution?

[BridgeAR]

@addaleax I am fine with that. We do not have any guarantees about the output, while it is heavily used and this is definitely something I could imagine others might have had expectations upon.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.53%. Comparing base (fc32ac2) to head (ab89426).
⚠️ Report is 206 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61029      +/-   ##
==========================================
- Coverage   88.53%   88.53%   -0.01%     
==========================================
  Files         703      703              
  Lines      208222   208544     +322     
  Branches    40142    40219      +77     
==========================================
+ Hits       184357   184639     +282     
- Misses      15852    15910      +58     
+ Partials     8013     7995      -18     

Files with missing lines	Coverage Δ
lib/internal/util/inspect.js	99.67% <100.00%> (+<0.01%)	⬆️

... and 89 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ljharb]

Does anybody else share my concern that the intention of the language is that it's not possible to determine if something's a Proxy? I realize node already exposes such a predicate, but this will make it much more visible.

[aduh95]

Does anybody else share my concern that the intention of the language is that it's not possible to determine if something's a Proxy? I realize node already exposes such a predicate, but this will make it much more visible.

That seems fine, browsers already out Proxy objects in their devtool, we do on the REPL already, and it seems useful from the user perspective.

[jasnell]

@ljharb ... I think there's a balance needed here. Yes, the language intends proxies to be opaque but the requirements of debugging when things go wrong require us to at least know that something is a proxy or not. They are opposing requirements. I think this PR is at least a net improvement

[ljharb]

In the dev tools, and in console.log, and in the repl, is fine, because none of these are exposed to actual developer code. Why util.inspect instead of just console.log?

[LiviaMedeiros]

Given that util.types.isProxy(suspiciousObject) and util.inspect(suspiciousObject, { showProxy: true }) exist, already making proxies not fully opaque, this looks reasonable.

[jasnell]

In the dev tools, and in console.log, and in the repl, is fine, because none of these are exposed to actual developer code. Why util.inspect instead of just console.log?

@ljharb ... really because util.inspect is fully intended to be, and documented, as a debugging tool only. The docs explicitly call that out. It's also specifically the thing that allows Node.js' console.log to work.

https://nodejs.org/docs/latest/api/util.html#utilinspectobject-showhidden-depth-colors

The util.inspect() method returns a string representation of
object that is intended for debugging. The output of util.inspect
may change at any time and should not be depended upon 
programmatically.

[nodejs-github-bot]

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

[nodejs-github-bot]

Landed in dc97b50