test for unusual error cases: verify that module require()
falls back to index if package.json names a missing file and
throws an error if package.json is unparseable.
PR-URL: https://github.com/nodejs/node/pull/23285
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
There are many things I might want to know about if I'm reading the
introduction of the README file for Node.js: Where to get help, what the
latest release is, how to compile from source, where to report bugs, how
to contribute...
One thing I cannot imagine wondering about is, "I wonder if there is a
foundation that supports Node.js." Move that sentence to the end of the
paragraph as it is designed to serve the project and not the end user.
Bonus: This removes a usage of passive voice.
The Linux kernel README does not mention the Linux Foundation.
https://github.com/torvalds/linux/blob/master/README
The jQuery README does not mention the JS Foundation.
https://github.com/jquery/jquery/blob/master/README.md
(It does mention the no-longer-extant jQuery Foundation but only because
the Foundation itself apparently had coding standards.)
The Python README only mentions the Python Software Foundation as the
copyright owner.
The Apache httpd README does mention the Apache Software Foundation
although it does not link to it and it is mentioned in passing rather
than being the topic of a declarative sentence.
PR-URL: https://github.com/nodejs/node/pull/23073
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
For safer shutdown, we should destroy the platform – and background
threads - before the tracing infrastructure is destroyed. This change
fixes the relative order of NodePlatform disposition and the tracing
agent shutting down. This matches the nesting order for startup.
Make the tracing agent own the tracing controller instead of platform
to match the above.
Fixes: https://github.com/nodejs/node/issues/22865
PR-URL: https://github.com/nodejs/node/pull/22938
Reviewed-By: Eugene Ostroukhov <eostroukhov@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
- Document `defaultEncoding`. This was previously undocumented.
- Clarify `decodeStrings`. In particular, the previous description was
talking about decoding, which matches the unfortunate option name,
but what actually happens is usually refererred to as encoding
a string into a binary form.
PR-URL: https://github.com/nodejs/node/pull/23246
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reverting this enables us to provide slower, but longer-lasting
replacements for the deprecated APIs.
Original commit message:
Put back deleted V8_DEPRECATE_SOON methods
This partially reverts
https://chromium-review.googlesource.com/c/v8/v8/+/1177861,
which deleted many V8_DEPRECATE_SOON methods rather than moving them to
V8_DEPRECATED first. This puts them back and marks them V8_DEPRECATED.
Note V8_DEPRECATED that were deleted in the same CL stay deleted.
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
Bug: v8:7786, v8:8240
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I00330036d957f98dab403465b25e30d8382aac22
Reviewed-on: https://chromium-review.googlesource.com/1251422
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/branch-heads/7.0@{#49}
Cr-Branched-From: 6e2adae6f7f8e891cfd01f3280482b20590427a6-refs/heads/7.0.276@{#1}
Cr-Branched-From: bc08a8624cbbea7a2d30071472bc73ad9544eadf-refs/heads/master@{#55424}
Refs: 9136dd8088
Refs: https://github.com/nodejs/node/issues/23122
PR-URL: https://github.com/nodejs/node/pull/23158
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Currently the WorkerDelegate class has a virtual function
but no virtual destructor which means that if delete is called on a
WorkerDelegate pointer to a derived instance, the derived destructor
will not get called.
The following warning is currently being printed when
compiling:
warning: delete called on 'node::inspector::WorkerDelegate' that is
abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete __ptr;
^
This commit adds a virtual destructor.
PR-URL: https://github.com/nodejs/node/pull/23215
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently the KeyPairGenerationConfigs class has a virtual function
but no virtual destructor which means that if delete is called on a
KeyPairGenerationConfig pointer to a derived instance, the derived
destructor will not get called.
The following warning is currently being printed when
compiling:
warning: delete called on 'node::crypto::KeyPairGenerationConfig' that
is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
delete __ptr;
This commit adds a virtual destructor.
PR-URL: https://github.com/nodejs/node/pull/23215
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently the Options class has a virtual function but no virtual
destructor which means that if delete is called on a Options pointer
to a derived instance, the derived destructor will not get called.
The following warning is currently being printed when
compiling:
warning: delete called on non-final 'node::PerIsolateOptions' that has
virtual functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
delete __ptr;
This commit adds a virtual destructor.
PR-URL: https://github.com/nodejs/node/pull/23215
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently, we have a 48/72 rule for how many hours a pull request should
be left open at a minimum. Unfortunately, whether a pull request should
be left open for 48 or 72 hours is often unclear. The 72 hours is
required if it is a weekend. If I open a pull request on a Friday
morning, does it need to stay open 48 hours or 72 or something in
between? Does it matter if I'm in one time zone or another?
The 48/72 rule predates our fast-tracking process. Given the ability to
fast-track trivial pull requests, there should be little disadvantage to
leaving significant changes open for 72 hours instead of 48 hours, and
arguably considerable advantage in terms of allowing people sufficient
time to review things.
So to simplify, standardize on 72 hours. Weekend or not, 72 hours. Easy.
PR-URL: https://github.com/nodejs/node/pull/22275
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Jon Moss <me@jonathanmoss.me>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Coe <bencoe@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Rod Vagg <rod@vagg.org>
Allow reading from stdio streams that are conventionally
associated with process output, since this is only convention.
This involves disabling the oddness around closing stdio
streams. Its purpose is to prevent the file descriptors
0 through 2 from being closed, since doing so can lead
to information leaks when new file descriptors are being
opened; instead, not doing anything seems like a more
reasonable choice.
Fixes: https://github.com/nodejs/node/issues/21203
PR-URL: https://github.com/nodejs/node/pull/23053
Reviewed-By: James M Snell <jasnell@gmail.com>
