The `assert.CallTracker` API has been deprecateed since v20. The
`node:test` `mock.fn` API provides a better alternative for the
functionality.
PR-URL: https://github.com/nodejs/node/pull/58006
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Jacob Smith <jacob@frende.me>
Reviewed-By: Edy Silva <edigleyssonsilva@gmail.com>
Co-Authored-By: richardlau - Richard Lau <rlau@redhat.com>
PR-URL: https://github.com/nodejs/node/pull/58090
Refs: https://github.com/nodejs/node/issues/57934
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Michael Dawson <midawson@redhat.com>
Avoid that one AsyncLocalStore instance changes the state of another
AsyncLocalStore instance by restoring only the owned store instead
the complete AsyncContextFrame.
PR-URL: https://github.com/nodejs/node/pull/58149
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
I added this class in 823d86c47c in 2018
when we did not yet use `std::optional`. The last uses were removed in
5b9bf39b47, so remove it.
Refs: https://github.com/nodejs/node/pull/24234
Refs: https://github.com/nodejs/node/pull/55368
PR-URL: https://github.com/nodejs/node/pull/58168
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/58141
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Escape the > metachar in vcbuild.bat to avoid that a file named as the
major node version number is created.
PR-URL: https://github.com/nodejs/node/pull/58157
Refs: https://github.com/nodejs/node/pull/57991
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
By the time the response event is emitted on the client's side, the
file may have already been fully piped and the stream pipe
may have been destroyed, so the test should not look for the
stream pipe in the snapshot.
PR-URL: https://github.com/nodejs/node/pull/58148
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Current alignment mislead doc reader into thinking
`importModuleDynamically` is a separate positional param right next to
`options`, which is incorrect and need to be fixed.
This misalignment is introduced in a PR merged in Feb 2024.
I belive this doc fix applies to node v20 and above.
Refs: https://github.com/nodejs/node/pull/51244
PR-URL: https://github.com/nodejs/node/pull/58145
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
currently when --watch is used, the argv arguments that
the target script receives are filtered so that they don't
include watch related arguments, however the current
filtering logic is incorrect and it causes some watch values
to incorrectly pass the filtering, the changes here address
such issue
PR-URL: https://github.com/nodejs/node/pull/57936
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
This will remove three of the four "A parse error occurred" issues
during JavaScript CodeQL scans. (The fourth occurrence is in our code
base, although it might be a false positive. Someone can figure that one
out sooner or later, but we certainly can bypass scanning V8 tools.)
PR-URL: https://github.com/nodejs/node/pull/58132
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This feature is enabled in stable Chrome 136 but not in V8 by
default.
PR-URL: https://github.com/nodejs/node/pull/58154
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
This feature is enabled in stable Chrome 136 but not in V8 by
default.
PR-URL: https://github.com/nodejs/node/pull/58154
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
we should not be blocking on the worker tasks on the
main thread in one go. Doing so leads to two problems:
1. If any of the worker tasks post another foreground task and wait
for it to complete, and that foreground task is posted right after
we flush the foreground task queue and before the foreground thread
goes into sleep, we'll never be able to wake up to execute that
foreground task and in turn the worker task will never complete, and
we have a deadlock.
2. Worker tasks can be posted from any thread, not necessarily
associated with the current isolate, and we can be blocking on a
worker task that is associated with a completely unrelated isolate
in the event loop. This is suboptimal.
However, not blocking on the worker tasks at all can lead to loss of
some critical user-blocking worker tasks e.g. wasm async compilation
tasks, which should block the main thread until they are completed,
as the documentation suggets. As a compromise, we currently only block
on user-blocking tasks to reduce the chance of deadlocks while making
sure that criticl user-blocking tasks are not lost.
PR-URL: https://github.com/nodejs/node/pull/58047
Refs: https://github.com/nodejs/node/pull/47452
Refs: https://github.com/nodejs/node/issues/54918
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
According to the documentation, the v8 tasks should be executed
based on priority. Previously we always execute the tasks in
FIFO order, this changes the NodePlatform implementation to
execute the higher priority tasks first. The tasks used to
schedule timers for the delayed tasks are run in FIFO order
since priority is irrelavent for the timer scheduling part
while the tasks unwrapped by the timer callbacks are still
ordered by priority.
PR-URL: https://github.com/nodejs/node/pull/58047
Refs: https://github.com/nodejs/node/pull/47452
Refs: https://github.com/nodejs/node/issues/54918
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
PR-URL: https://github.com/nodejs/node/pull/57916
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/57916
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/57916
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Vinícius Lourenço Claro Cardoso <contact@viniciusl.com.br>
Reviewed-By: James M Snell <jasnell@gmail.com>
From the source code, `readlinePromises.createInterface()` calls
`new Interface()` imported from `internal/readline/interface`, which
works the same as the non-promise version. If non-promise version
accepts options.signal, it should also work for
`readlinePromises.createInterface()`. Hence this information need to be
indicated in the documentation.
Refs: https://github.com/nodejs/node/blob/main/lib/readline/promises.js
PR-URL: https://github.com/nodejs/node/pull/55456
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The order of these calls is important. When the Isolate is disposed,
it may still post tasks to the platform, so it must still be registered
for the task runner to be found from the map. After the isolate is torn
down, we need to remove it from the map before we can free the address,
so that when another Isolate::Allocate() is called, that would not be
allocated to the same address and be registered on an existing map
entry.
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
As V8 is moving towards built-in CppHeap creation, change the
management so that the automatic CppHeap creation on Node.js's end
is also enforced at Isolate creation time.
1. If embedder uses NewIsolate(), either they use
IsolateSettings::cpp_heap to specify a CppHeap that will be owned
by V8, or if it's not configured, Node.js will create a CppHeap
that will be owned by V8.
2. If the embedder uses SetIsolateUpForNode(),
IsolateSettings::cpp_heap will be ignored (as V8 has deprecated
attaching CppHeap post-isolate-creation). The embedders need to
ensure that the v8::Isolate has a CppHeap attached while it's
still used by Node.js, preferably using v8::CreateParams.
See https://issues.chromium.org/issues/42203693 for details. In
future version of V8, this CppHeap will be created by V8 if not
provided, and we can remove our own "if no CppHeap provided,
create one" code in NewIsolate().
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
The `--expose_externalize_string` flag adds a new global.
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58070
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
James M Snell