PR-URL: https://github.com/nodejs/node/pull/60605
Fixes: https://github.com/nodejs/node/issues/60599
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Pietro Marchini <pietro.marchini94@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This should improve the readability, as well as the UX of cherry-picking
what dependency the user wants in their env.
PR-URL: https://github.com/nodejs/node/pull/60495
Reviewed-By: Jacob Smith <jacob@frende.me>
`src/node_modules.cc` needs to be consistent with `src/node_file.cc` in
how it translates the utf8 strings to `std::wstring` otherwise we might
end up in situation where we can read the source code of imported
package from disk, but fail to recognize that it is an ESM (or CJS) and
cause runtime errors. This type of error is possible on Windows when the
path contains unicode characters and "Language for non-Unicode programs"
is set to "Chinese (Traditional, Taiwan)".
See: #58768
PR-URL: https://github.com/nodejs/node/pull/60575
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Stefan Stojanovic <stefan.stojanovic@janeasystems.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
This allows us to set up fixtures for the benchmark suite only
once, which can save quite a bit of time when running benchmarks
that require tens of thousands of fixture files or more (e.g.
the module benchmarks).
PR-URL: https://github.com/nodejs/node/pull/60574
Fixes: https://github.com/nodejs/node/issues/58488
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Previously when the child process helpers are used to print
information about the failed expectations and the env of the
child process was overridden, it printed the entire env object,
which may be too much if the caller does something like
{ env: { ENV: 'var', ...process.env } } (which tend to be always
the case for specifying env because we need to copy the
process.env for dynamic library loading in the CI).
This updates it to only show the env vars that differ from
process.env for a cleaner log in the case of failure.
PR-URL: https://github.com/nodejs/node/pull/60556
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Otherwise, it can be virtually impossible to debug where these types
of errors originate from.
PR-URL: https://github.com/nodejs/node/pull/60593
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Similar to 2e2f4cd095, just missed them in that commit.
PR-URL: https://github.com/nodejs/node/pull/60592
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
It should remove both the error and the ready event listeners
attached when either of them fires, instead of removing only
the one whose corresponding event fires, otherwise the other
event listener will always get leaked.
PR-URL: https://github.com/nodejs/node/pull/60464
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
The test has been flaking due to either timeout or calling
uv_async_send on a closing/closed handle. As the test squeezes
too many independent test cases in one file, split it up to
avoid timing out on slower machines and aid debugging.
PR-URL: https://github.com/nodejs/node/pull/60491
Refs: https://github.com/nodejs/reliability/blob/main/reports/2025-10-29.md
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
The current 250ms timeout is too short for high-latency network
environments, causing connection failures in IPv4-only networks when
connecting to dual-stack hosts. This increases the timeout to 500ms
to better handle satellite, cellular, and geographically distant
connections.
The timeout should be reconsidered when parallel connections are
implemented as per RFC 8305.
Refs: https://github.com/nodejs/node/issues/54359
Refs: https://github.com/nodejs/node/issues/48145
PR-URL: https://github.com/nodejs/node/pull/60334
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
If the test does not use node:test, don't append the unnecessary
arguments to avoid cluttering the command line printed by the
test runner when the test fails.
PR-URL: https://github.com/nodejs/node/pull/60551
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Including `node.h` should not result in all of Node-API also being
available to callers. Users who want `node_api.h` contents should
explicitly include that header.
We currently include it specifically for `napi_addon_register_func`;
by moving that into `node_api_types.h` and including that instead,
we can reduce unintentionally included API surface a lot.
Refs: https://github.com/nodejs/node/pull/60345#issuecomment-3463904087
PR-URL: https://github.com/nodejs/node/pull/60496
Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
Reviewed-By: Chengzhong Wu <legendecas@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
A regression introduced by
0136bb0ee8
made it possible for the fast path to be hit with non-array-buffer
arguments despite that the fast paths could only deal with array
buffer arguments, so that it can crash with invalid arguments
once crypto.timingSafeEqual is optimized instead of throwing
validation errors as usual. This adds validation to the fast path
so that it throws correctly.
PR-URL: https://github.com/nodejs/node/pull/60538
Fixes: https://github.com/nodejs/node/issues/60537
Refs: https://github.com/nodejs-private/node-private/pull/749
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Previously, we ignored all indicators of the body (content-length or
transfer-encoding headers) and treated any information following
the headers as part of the upgraded stream. We now fully process the
requests bodies separately instead, allowing us to automatically handle
correct parsing of the body like any other HTTP request.
This is a breaking change if you are currently accepting HTTP Upgrade
requests with request bodies successfully, or if you use
socket-specific fields & methods on the upgraded stream argument.
In the former case, before now you will have received the request body
and then the upgraded data on the same stream without any distinction
or HTTP parsing applied. Now, you will need to separately read the
request body from the request (the 1st argument) and the upgraded
data from the upgrade stream (the 2nd argument). If you're not
interested in request bodies, you can continue to just read from the
upgrade stream directly.
In the latter case, if you want to access the raw socket, you should do
so via request.socket, instead of expecting the 2nd argument to be a
socket.
PR-URL: https://github.com/nodejs/node/pull/60016
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
