Repository navigation
console.assert(false, Symbol()) throws #49680
Description
Activity
Working as expected/documented. Try this instead:
console.assert(false, "%o", { hello: "world" }) // or even just: console.assert(false, "", { hello: "world" })
It wouldn't be hard to use
util.inspect()by default but:- it's the documented behavior
- is mandated by the console spec
- would be a rather visible change (can spam large amounts of text to the console) and therefore at least a semver-major change
You're welcome to open a pull request and see how it's received if you still think it's a good idea but be prepared for rejection.
Yes, I'm pretty sure. The more human-readable prose from the MDN lemma (emphasis mine):
A list of JavaScript objects to output. The string representations of each of these objects are appended together in the order listed and output.
It's only when you use a message format string that object formatting comes into play:
JavaScript objects with which to replace substitution strings within msg.
After further investigation, here's the erroneous line:
node/lib/internal/console/constructor.js
Line 435 in cd97e28
👆 this isn't precisely spec compliant. Why? Because there's supposed to be this:
which means something more like this:
assert(expression, ...args) { if (!expression) { if (typeof args[0] === "string") { // if you provide a fmt string, it still gets used (first arg) args[0] = `Assertion failed: ${args[0]}` } else { // but if it's anything else, it's not stringified as a format string; // its just an object to be printed. so we prepend a fmt string arg (with no specifiers // that would eat any user-supplied objects) as a nice "Assertion failed" message ArrayPrototypeUnshift(args, "Assertion failed") } // The arguments will be formatted in warn() again ReflectApply(this.warn, this, args); } },
you can see a bug here from the current Node.js impl that highlights what's happening:
const mySymbol = Symbol() console.assert(false, mySymbol) // THROWS because Symbol() cant be stringified like `symbol string: ${Symbol()}`!
the mdn thing you cited:
A list of JavaScript objects to output. The string representations of each of these objects are appended together in the order listed and output.
this same language "string representations" is also used in console.info() and other console methods to mean the formatted pretty output not the
.toString()version:
https://developer.mozilla.org/en-US/docs/Web/API/console/info
also backed up by someone from the whatwg/console repo:
My understanding of the spec is the object {hello: "world"} would get passed as a member of args (eg, ["Assertion failed", {hello: "world"}]) to Printer, which is implementation defined. Converting a POJO to the string "[object Object]" is certainly a valid way of being implementation defined, but I wouldn't judge it "to be maximally useful and informative."
so in summary it would seem:
[object Object]is a valid string representation of the object- ...but it's not very helpful
- there's the edge case with
Symbol()not being stringifiable in the wayconsole.assert()is implemented - most other runtimes Chrome/Firefox/Deno/Bun do it where
console.assert(false, {a:1})is properly inspected; Node.js is the outlier.
i also am making an effort to clarify the mdn wording that had us all confused 🤣 mdn/content#29172
- changed the title
[-]`console.assert(false, { hello: "world" })` logs `[object Object]` instead of inspecting the object[/-][+]`console.assert(false, Symbol())` throws[/+]on Sep 19, 2023 Changed title and body to reflect exact buggy impl:
console.assert(false, Symbol())
- added a commit that references this issue
on Sep 19, 2023 @bnoordhuis I believe it's fine to handle it that way. It aligns well with the other APIs where the object would be printed in a human readable way. There's also already an open PR and I guess we could reopen the issue as such?
Yeah, I'm fine with that, I don't really have a strong opinion either way except that changing the default should be a semver-major change.
Reacted by Yagiz Nizipli- added a commit that references this issue
on Nov 1, 2023
Version
v20.6.1
Platform
Linux PIG-2016 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
console
What steps will reproduce the bug?
node -e 'console.assert(false, Symbol())'How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
What do you see instead?
Additional information
No response