Expands the existing restrictions around not using literal messages
to the `not` variants of `strictEqual` and `deepStrictEqual`, and
forbids `assert()` where the second argument is a non-string literal,
which almost always is a mis-typed `assert.strictEquals()`.
PR-URL: https://github.com/nodejs/node/pull/59147
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Chemi Atlow <chemi@atlow.co.il>
I missed marking a couple of test cases flaky in my previous PR:
https://github.com/nodejs/node/pull/58583
tests missed were:
- parallel.test-inspector-network-content-type
- benchmark.test-benchmark-websocket
After marking the above flaky I re-ran a test build and noticed
the build still failed.
Unfortuantely the build still fails because the build detects that
node process are left behind after the tests, presumably because tests
that spawn child processes are being timed out and only the parent
process is killed off, leaving the child processes behind.
see: https://github.com/nodejs/node/pull/59014#issuecomment-3057162303
We've decided to skip these tests until the underlying issue is
resolved.
The tests being skipped are:
- parallel.test-http-proxy-fetch
- parallel.test-https-proxy-fetch
- benchmark.test-benchmark-websocket
- parallel.test-inspector-network-fetch
- parallel.test-inspector-network-content-type
- es-module.test-wasm-web-api
- parallel.test-fetch
- parallel.test-without-async-context-frame
- report.test-report-exclude-network
PR-URL: https://github.com/nodejs/node/pull/59014
Reviewed-By: Richard Lau <richard.lau@ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Underlying issues still need to be investigated
but this will prevent these failures from failing
the daily builds.
Timeouts:
- parallel.test-http-proxy-fetch
- parallel.test-https-proxy-fetch
- benchmark.test-benchmark-websocket
- parallel.test-inspector-network-fetch
- es-module.test-wasm-web-api
- parallel.test-fetch
- parallel.test-without-async-context-frame
- report.test-report-exclude-network
Flaky test:
- parallel.test-process-cpuUsage
PR-URL: https://github.com/nodejs/node/pull/58583
Refs: https://github.com/nodejs/node/issues/58582
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
There are several cleanups here that are not just style nits...
1. The `common.isMainThread` was just a passthrough to the
`isMainThread` export on the worker_thread module. It's
use was inconsistent and just obfuscated the fact that
the test file depend on the `worker_threads` built-in.
By eliminating it we simplify the test harness a bit and
make it clearer which tests depend on the worker_threads
check.
2. The `common.isDumbTerminal` is fairly unnecesary since
that just wraps a public API check.
3. Several of the `common.skipIf....` checks were inconsistently
used and really don't need to be separate utility functions.
A key part of the motivation here is to work towards making more
of the tests more self-contained and less reliant on the common
test harness where possible.
PR-URL: https://github.com/nodejs/node/pull/56712
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
`Environment::GetCurrent` may not available in the context of OOM.
Removes the cyclic `Environment::GetCurrent` and `env->isolate()`
calls to ensure both `isolate` and `env` is present if available.
However, this behavior is not guaranteed. As
`Environment::GetCurrent` didn't allocate new handles in the heap,
when a Context is entered it can still get the valid env pointer.
Removes the unstable assertion of the absence of env in the test.
PR-URL: https://github.com/nodejs/node/pull/44398
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Comparing any value to any non-RegExp literal or undefined using
strictEqual (or notStrictEqual) passes if and only if deepStrictEqual
(or notDeepStrictEqual, respectively) passes.
Unnecessarily using deep comparisons adds confusion.
This patch adds an ESLint rule that forbids the use of deepStrictEqual
and notDeepStrictEqual when the expected value (i.e., the second
argument) is a non-RegExp literal or undefined.
For reference, an ESTree literal is defined as follows.
extend interface Literal <: Expression {
type: "Literal";
value: string | boolean | null | number | RegExp | bigint;
}
The value `undefined` is an `Identifier` with `name: 'undefined'`.
PR-URL: https://github.com/nodejs/node/pull/40634
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Voltrex <mohammadkeyvanzade94@gmail.com>
Multi-line JSON is more human readable, but harder for log aggregators
to consume, they usually require a log message per line, particularly
for JSON. Compact output will be consumable by aggregators such as EFK
(Elastic Search-Fluentd-Kibana), LogDNA, DataDog, etc.
PR-URL: https://github.com/nodejs/node/pull/32254
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
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>
It's likely that anyone using `process.report.getReport()` will be
processing the return value thereafter (e.g., filtering fields or
redacting secrets). This change eliminates boilerplate by calling
`JSON.parse()` on the return value.
Also modified the `validateContent()` and `validate()` test helpers in
`test/common/report.js` to be somewhat more obvious and helpful. Of
note, a report failing validation will now be easier (though still not
_easy_) to read when prepended to the stack trace.
- Refs: https://github.com/nodejs/diagnostics/issues/315
PR-URL: https://github.com/nodejs/node/pull/28630
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jiawen Geng <technicalcute@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Rich Trott <rtrott@gmail.com>
In the code base the word `report` is almost only used to refer to
the diagnostic report when it's a noun, and it's programmable
interface `process.report()` it not prefixed, so `report` should be
unambiguous enough to use without `diagnostic`.
PR-URL: https://github.com/nodejs/node/pull/27312
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This commit removes process.report.setOptions(). Instead of
using complex configuration synchronization between C++ and
JS, this commit introduces individual getters and setters.
PR-URL: https://github.com/nodejs/node/pull/26414
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Wyatt Preul <wpreul@gmail.com>
