-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
Support util.inspect.custom as a public symbol #20821
Comments
I think the first option would be okay. Do you want to open a PR with it? |
@addaleax Sure! |
I like the idea of the first option! |
I'm also in favor of the first option, though I am not sure to see if this would harm node's core as a side effect. |
First option sounds good to me as well. |
/ping @jakearchibald |
Using a global name kinda gives us the same problem we had the in the first place, it's just that the name is longer so less likely to clash with existing code. However, it's probably the best thing to do for multi-realm environments like the browser. |
Yeah running into this now. Unfortunately all my proxies just print like this:
Since this lib should work everywhere, I dont want to import // in the proxy get
if (typeof key === 'symbol' && String(key) === 'Symbol(util.inspect.custom)') {
// super hacky method of supporting nodejs printing values
return () => descriptor.copy || descriptor.base;
} ( Happy to hear of another solution if there is one :) ) Thanks for your hard work everyone! |
Define `util.inspect.custom` as `Symbol.for("nodejs.util.inspect.custom")` rather than `Symbol("util.inspect.custom")`. This allows `inspect` hooks to easily/safely be defined in non-Node.js environments. Fixes: nodejs#20821 Refs: nodejs#22684 PR-URL: nodejs#20857 Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: John-David Dalton <[email protected]>
Define `util.inspect.custom` as `Symbol.for("nodejs.util.inspect.custom")` rather than `Symbol("util.inspect.custom")`. This allows `inspect` hooks to easily/safely be defined in non-Node.js environments. Fixes: #20821 Refs: #22684 Backport-PR-URL: #23039 PR-URL: #20857 Reviewed-By: Ruben Bridgewater <[email protected]> Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Tiancheng "Timothy" Gu <[email protected]> Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Michaël Zasso <[email protected]> Reviewed-By: John-David Dalton <[email protected]>
Please consider supporting
util.inspect.custom
as a public/global symbol either by:util.inspect.custom
from a private symbol (e.g.Symbol('util.inspect.custom')
) to a public symbol (e.g.Symbol.for('util.inspect.custom')
)or:
"inspect"
is currently accepted as a (deprecated) fallback for the symbolChanging it from a string to a symbol was a great idea 🎉 and it's a perfect use case for a symbol, but, as mentioned here, making it private makes it painful to write code that both a) provides an
inspect
hook if it's loaded in node and b) works seamlessly in the browser if it's not.A workaround has been implemented as an NPM module, inspect-custom-symbol (cc @mafintosh), which uses the
browser
field in itspackage.json
to provide a substitute symbol without pulling in theutil
library in bundlers such as Browserify and Webpack. It's much better than trying to work around this with a tower of late-boundtypeof util.inspect.custom
checks, but it doesn't fix the underlying issue and it's not ideal:The text was updated successfully, but these errors were encountered: