util: displaying non-enumerable values

[ljharb]

Currently, in node v17.3:

let e = new Error('a', { cause: 'b' });
e.stack = '';
e.enumerable = true;

e[Symbol('enumerable')] = true;
assert(Object.prototype.propertyIsEnumerable.call(e, Symbol.iterator));
// symbols can be enumerable too; it affects Object.assign and object spread semantics

Object.defineProperty(e, Symbol('non-enumerable'), { enumerable: false, value: true });
assert.equal(util.inspect(e), `[Error: a] {
  enumerable: true,
  [Symbol(enumerable)]: true
  [cause]: 'b'
}`);

The brackets on "cause" are apparently to denote that it's non-enumerable - but there's also brackets on the enumerable symbol, and the non-enumerable symbol is omitted entirely.

Should perhaps non-enumerability be indicated with something that doesn't have an existing meaning?

cc @nodejs/util

[BridgeAR]

If you like to change that, I think best would be a concrete suggestion. Non-enumerable and enumerable properties are currently distinguished with colors:

We currently use all kinds of brackets ((something), <something> and {something}). Mostly, they are already used for different things as special characters become rarer. We also use stars * as reference and all quotes. The latter depending on the string type (", ' and `). The hash (#) is not used so far but the language uses it for private properties and using it else wise is likely confusing. We do not yet use: ~, +, -, !, ^, §, $, %, &, |. I am not certain if those are suitable though.

Non-enumerable properties are not visible by default using util.inspect(). There are a few explicit exceptions and cause is such an exception. Otherwise they are only visible when the showHidden option is set to true.

[ljharb]

oof, ok - colors don't show up on every terminal, and using color to differentiate things tends to violate a11y.

My concrete suggestions for non-enumerables would be one of the following:

• two square brackets instead of one (so, [[cause]] or [[Symbol(non-enumerable)]])
• (non-enumerable) cause: 'b' or (hidden) cause: 'b' - more wordy but much harder to misinterpret (altho i'd have named showHidden differently, because non-enumerable things aren't "hidden" as much as they're simply not enumerable)
• something else?

As for color, i'd expect non-enumerables to be in gray or something, and either way Symbol(enumerable) is enumerable, so it should look exactly the same as enumerable: true - enumerability is a different property from "appears in a for-in loop".

[BridgeAR]

Thinking about it: we could remove the brackets around symbols. They would still be distinguishable from regular properties due to their round brackets without quotes.

[ljharb]

While I see the consistency, this is very surprising to me since it deviates from the language itself.

Also, "computed properties" are not just "string properties that can't be an IdentifierName", they're also "symbol properties".

[ljharb]

What do you think about using brackets for Symbols - the way the language uses them - and one of these options for non-eumerable things?

[ljharb]

ping @BridgeAR thoughts?

[ljharb]

We discussed this at the Collab Summit this week, and due to the following considerations:

1. minimizing disruption/changes to output
2. square brackets are already used for a number of "special" things, including a data __proto__ property, Symbol.toStringTag values, null objects, etc, so we already wouldn't be able to have square brackets mean only "computed properties"

Therefore, let's go with "enumerable Symbols do not have square brackets", so that all non-enumerables use square brackets. (there's also another inconsistency discovered during this investigation where bracketed string keys aren't escaped the same way as unbracketed ones are, so i'll fix that as well in the same PR)