This completely refactors the `expectsError` behavior: so far it's
almost identical to `assert.throws(fn, object)` in case it was used
with a function as first argument. It had a magical property check
that allowed to verify a functions `type` in case `type` was passed
used in the validation object. This pattern is now completely removed
and `assert.throws()` should be used instead.
The main intent for `common.expectsError()` is to verify error cases
for callback based APIs. This is now more flexible by accepting all
validation possibilites that `assert.throws()` accepts as well. No
magical properties exist anymore. This reduces surprising behavior
for developers who are not used to the Node.js core code base.
This has the side effect that `common` is used significantly less
frequent.
PR-URL: https://github.com/nodejs/node/pull/31092
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
This is only active if the `showHidden` option is truthy.
The implementation is a trade-off between accuracy and performance.
This will miss properties such as properties added to built-in data
types.
The goal is mainly to visualize prototype getters and setters such as:
class Foo {
ownProperty = true
get bar() {
return 'Hello world!'
}
}
const a = new Foo()
The `bar` property is a non-enumerable property on the prototype while
`ownProperty` will be set directly on the created instance.
The output is similar to the one of Chromium when inspecting objects
closer. The output from Firefox is difficult to compare, since it's
always a structured interactive output and was therefore not taken
into account.
PR-URL: https://github.com/nodejs/node/pull/30768
Fixes: https://github.com/nodejs/node/issues/30183
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
This changes the `compact` default from `true` to `3`. That mode
changes arrays to be grouped together, it alignes multiple small
entries on a single line in similar to `compact` true but only for
the most inner three depth levels and the closing brackets are
always on the same indentation as the openeing of the object instead
of at the same line as another property.
Big strings will be naturally broken into multiple lines instead of
having one huge line that is not well readable.
The output size mainly stays the same that way while it will be
smaller in case of big arrays.
Increasing the `breakLength` to 80 adjusts for most terminals that
support at least 80 characters in a single line and improves the
general output that way. A lot of calculations use the `breakLength`
to determine the concrete behavior.
PR-URL: https://github.com/nodejs/node/pull/27109
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Minwoo Jung <minwoo@nodesource.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
This makes sure the internal `stylize` function is not used to render
anything and instead just uses the regular inspect function in case
of reaching the maximum depth level.
PR-URL: https://github.com/nodejs/node/pull/24971
Refs: https://github.com/nodejs/node/issues/24765
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Split test-whatwg-encoding-textdecoder.js into:
- `test-whatwg-encoding-custom-textdecoder.js` which tests
Node.js-specific behaviors
- `test-whatwg-encoding-custom-textdecoder-api-invalid-label.js` which
is a customized version of the WPT counterpart
- `test-whatwg-encoding-custom-api-basics.js` which is the part of
`test-whatwg-encoding-api-basics.js` that can be run without ICU
- `test-whatwg-encoding-api-basics.js` which can be replaced with WPT
later.
PR-URL: https://github.com/nodejs/node/pull/25155
Reviewed-By: James M Snell <jasnell@gmail.com>
