Add es-module to CI_JS_SUITES/js_test_suites, so that tests run in CI.
Update test/README adding es-module section.
PR-URL: https://github.com/nodejs/node/pull/15276
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Yuta Hiroto <hello@about-hiroppy.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
"jslint" is the name of a tool that actually is not used, which can
cause confusion.
PR-URL: https://github.com/nodejs/node/pull/15272
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
Tries to achieve the same effect as
https://github.com/nodejs/node/pull/13658 without breaking source
tarballs. Presumably if `tools/eslint` wasn't there at all, people
would notice in the PR review!
PR-URL: https://github.com/nodejs/node/pull/15441
Fixes: https://github.com/nodejs/node/issues/14513
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when building with --enable-static and running the test target
the following error will be reported:
Building addon
/node/test/addons/01_function_arguments/
env: ./node: No such file or directory
make[1]: *** [test/addons/.buildstamp] Error 1
Note that this is with a clean build where no prior node executable was
built.
This commit suggests only running the cctest target when --enable-static
is specified.
PR-URL: https://github.com/nodejs/node/pull/14892
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Lance Ball <lball@redhat.com>
Use a standard hash-based container instead of the custom included
red/black tree implementation. There is likely no noticeable
performance difference, and if there is one, it is very likely
to be an improvement.
PR-URL: https://github.com/nodejs/node/pull/14826
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
At long last: The initial *experimental* implementation of HTTP/2.
This is an accumulation of the work that has been done in the nodejs/http2
repository, squashed down to a couple of commits. The original commit
history has been preserved in the nodejs/http2 repository.
This PR introduces the nghttp2 C library as a new dependency. This library
provides the majority of the HTTP/2 protocol implementation, with the rest
of the code here providing the mapping of the library into a usable JS API.
Within src, a handful of new node_http2_*.c and node_http2_*.h files are
introduced. These provide the internal mechanisms that interface with nghttp
and define the `process.binding('http2')` interface.
The JS API is defined within `internal/http2/*.js`.
There are two APIs provided: Core and Compat.
The Core API is HTTP/2 specific and is designed to be as minimal and as
efficient as possible.
The Compat API is intended to be as close to the existing HTTP/1 API as
possible, with some exceptions.
Tests, documentation and initial benchmarks are included.
The `http2` module is gated by a new `--expose-http2` command line flag.
When used, `require('http2')` will be exposed to users. Note that there
is an existing `http2` module on npm that would be impacted by the introduction
of this module, which is the main reason for gating this behind a flag.
When using `require('http2')` the first time, a process warning will be
emitted indicating that an experimental feature is being used.
To run the benchmarks, the `h2load` tool (part of the nghttp project) is
required: `./node benchmarks/http2/simple.js benchmarker=h2load`. Only
two benchmarks are currently available.
Additional configuration options to enable verbose debugging are provided:
```
$ ./configure --debug-http2 --debug-nghttp2
$ NODE_DEBUG=http2 ./node
```
The `--debug-http2` configuration option enables verbose debug statements
from the `src/node_http2_*` files. The `--debug-nghttp2` enables the nghttp
library's own verbose debug output. The `NODE_DEBUG=http2` enables JS-level
debug output.
The following illustrates as simple HTTP/2 server and client interaction:
(The HTTP/2 client and server support both plain text and TLS connections)
```jt client = http2.connect('http://localhost:80');
const req = client.request({ ':path': '/some/path' });
req.on('data', (chunk) => { /* do something with the data */ });
req.on('end', () => {
client.destroy();
});
// Plain text (non-TLS server)
const server = http2.createServer();
server.on('stream', (stream, requestHeaders) => {
stream.respond({ ':status': 200 });
stream.write('hello ');
stream.end('world');
});
server.listen(80);
```
```js
const http2 = require('http2');
const client = http2.connect('http://localhost');
```
Author: Anna Henningsen <anna@addaleax.net>
Author: Colin Ihrig <cjihrig@gmail.com>
Author: Daniel Bevenius <daniel.bevenius@gmail.com>
Author: James M Snell <jasnell@gmail.com>
Author: Jun Mukai
Author: Kelvin Jin
Author: Matteo Collina <matteo.collina@gmail.com>
Author: Robert Kowalski <rok@kowalski.gd>
Author: Santiago Gimeno <santiago.gimeno@gmail.com>
Author: Sebastiaan Deckers <sebdeckers83@gmail.com>
Author: Yosuke Furukawa <yosuke.furukawa@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/14239
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Handle spaces in the path to python.exe, in case it is installed
under some directory like "C:\Program Files".
PR-URL: https://github.com/nodejs/node/pull/14546
Reviewed-By: Timothy Gu <timothygu99@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
`vcbuild.bat test-v8` : Runs unit test from v8 repo
`vcbuild.bat test-v8-intl` : Runs intl test from v8 repo
`vcbuild.bat test-v8` : Runs benchmarks from v8 repo
The runs needs
https://www.chromium.org/developers/how-tos/install-depot-tools
installed on the machine expects environment variable
`DEPOT_TOOLS_PATH` to be set to the path.
Set environment variable `DISABLE_V8_I18N` to disable i18n.
PR-URL: https://github.com/nodejs/node/pull/13992
Refs: https://github.com/nodejs/node/pull/4704
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Refactors cpplint slightly to allow multiple runs of it. This allows
downstream projects to run cpplint on their dependencies.
PR-URL: https://github.com/nodejs/node/pull/14116
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Kunal Pathak <kunal.pathak@microsoft.com>
Reviewed-By: João Reis <reis@janeasystems.com>
When building in machines with multiple versions of Visual Studio
installed, node-gyp should respect the vs2015/vs2017 arguments passed
to vcbuild.bat instead of relying on its own detection mechanism.
PR-URL: https://github.com/nodejs/node/pull/13911
Reviewed-By: Refael Ackermann <refack@gmail.com>
vcbuild.bat should detect what version of Visual Studio to use, it
should simply work without any parameter if any supported version is
installed. It should default to the latest version, to match the
behavior of `node-gyp`.
PR-URL: https://github.com/nodejs/node/pull/13911
Fixes: https://github.com/nodejs/node/issues/13641
Reviewed-By: Refael Ackermann <refack@gmail.com>
Make the "can we lint?" check in Makefile and vcbuild.bat depend on
bin/eslint.js rather than lib/eslint.js. In ESLint 4.0.0, lib/eslint.js
is not present. The lint rules call bin/eslint.js so check for that
instead.
PR-URL: https://github.com/nodejs/node/pull/13645
Reviewed-By: Teddy Katz <teddy.katz@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Sam Roberts <vieuxtech@gmail.com>
Reviewed-By: Alexey Orlenko <eaglexrlnk@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
* Set default to `vs2015` since `vs2017` is not CI-green yet
* changes vcbuild.bat arg from `vc2015` to `vs2015`/`vs2017`
`vc` as in Visual C++ is actually versions 14.0 or 14.10
`vs` as in Visual Studio is 2015 or 2017
Ref: http://lists.boost.org/Archives/boost/2017/03/233597.php🤦
* keep `vc2015` for backward compatibility but "undocumented"
* tools: transplant vswhere wrapper from `msvs-com-helper`
Ref: https://github.com/node4good/msvs-com-helper
PR-URL: https://github.com/nodejs/node/pull/11852
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Not all CLI options are supported, those that are problematic from a
security or implementation point of view are disallowed, as are ones
that are inappropriate (for example, -e, -p, --i), or that only make
sense when changed with code changes (such as options that change the
javascript syntax or add new APIs).
PR-URL: https://github.com/nodejs/node/pull/12028
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>
Running the addon tests before the parallel, sequential, etc. tests
can be a problem if there is a bug in node that prevents the
addon tests from running properly. When the addon tests fail for any
reason, then none of the other tests (e.g. parallel, etc.)
are executed.
Running the addon tests last fixes this.
Refs: https://github.com/nodejs/node/issues/12031
PR-URL: https://github.com/nodejs/node/pull/12062
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Refael Ackermann <refack@gmail.com>
MSBuild invokes cl.exe with /MP (set in common.gypi), making it
compile sources in parallel using a number of internal processes
equal to the number of effective processors. MSBuild /m uses a
similar mechanism, so the number of compiler processes can grow to
the number of effective processors squared.
This limits MSBuild to 2 processes, to still use some parallelization
while requiring less memory. Cl.exe is still invoked with /MP, thus
the maximum number of processes is limited to twice the number of
effective processors.
PR-URL: https://github.com/nodejs/node/pull/12184
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Add support for abi stable module API (N-API) as "Experimental feature".
The goal of this API is to provide a stable Node API for native
module developers. N-API aims to provide ABI compatibility guarantees
across different Node versions and also across different
Node VMs - allowing N-API enabled native modules to just work
across different versions and flavors of Node.js without recompilation.
A more detailed introduction is provided in:
https://github.com/nodejs/node-eps/blob/master/005-ABI-Stable-Module-API.md
and https://github.com/nodejs/abi-stable-node/blob/doc/VM%20Summit.pdf.
The feature, during its experimental state, will be guarded by a runtime
flag "--napi-modules". Only when this flag is added to the command line
will N-API modules along with regular non N-API modules be supported.
The API is defined by the methods in "src/node_api.h" and
"src/node_api_types.h". This is the best
starting point to review the API surface. More documentation will follow.
In addition to the implementation of the API using V8, which is included
in this PR, the API has also been validated against chakracore and that
port is available in
https://github.com/nodejs/abi-stable-node/tree/api-prototype-chakracore-8.x.
The current plan is to provide N-API support in versions 8.X and 6.X
directly. For older versions, such as 4.X or pre N-API versions of 6.X,
we plan to create an external npm module to provide a migration path
that will allow modules targeting older Node.js versions to use the API,
albeit without getting the advantage of not having to recompile.
In addition, we also plan an external npm package with C++ sugar to
simplify the use of the API. The sugar will be in-line only and will
only use the exported N-API methods but is not part of the N-API
itself. The current version is in:
https://github.com/nodejs/node-api.
This PR is a result of work in the abi-stable-node repo:
https://github.com/nodejs/abi-stable-node/tree/doc,
with this PR being the cumulative work on the api-prototype-8.x
branch with the following contributors in alphabetical order:
Author: Arunesh Chandra <arunesh.chandra@microsoft.com>
Author: Gabriel Schulhof <gabriel.schulhof@intel.com>
Author: Hitesh Kanwathirtha <hiteshk@microsoft.com>
Author: Ian Halliday <ianhall@microsoft.com>
Author: Jason Ginchereau <jasongin@microsoft.com>
Author: Michael Dawson <michael_dawson@ca.ibm.com>
Author: Sampson Gao <sampsong@ca.ibm.com>
Author: Taylor Woll <taylor.woll@microsoft.com>
PR-URL: https://github.com/nodejs/node/pull/11975
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/11992
Fixes: https://github.com/nodejs/node/issues/11971
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Vse Mozhet Byt <vsemozhetbyt@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
This PR adds cpp linting to windows build script. After this change,
running command `vcbuild lint` will run both cpp linting and javascript
linting on a windows machine.
PR-URL: https://github.com/nodejs/node/pull/11856
Fixes: https://github.com/nodejs/node/issues/11816
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This just adds an additional make target (`make test-node-inspect`) but
will not include the new debugger in releases.
PR-URL: https://github.com/nodejs/node/pull/10187
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Replace node-weak with a small hand-rolled add-on. We can now drop
node-weak and nan, reducing the size of the source tree by about 750 kB
and the size of the tarball by about 150-300 kB.
PR-URL: https://github.com/nodejs/node/pull/11239
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
vcbuild doesn't sign by default since
92ed1ab450, but there might be people who
haven't noticed the change. This adds a message informing them that
"nosign" is no longer necessary.
PR-URL: https://github.com/nodejs/node/pull/11119
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Makes the default build on Windows not try to sign the node.exe
binary after a build. Instead the 'sign' flag now indicates that the
binary should be signed. The 'nosign' flag is left as a noop.
Reviewed-By: Nikolai Vavilov <vvnicholas@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: João Reis <reis@janeasystems.com>
PR-URL: https://github.com/nodejs/node/pull/10156
The tick-processor tests are inherently non-deterministic. They
therefore have false negatives from time to time. They also
sometimes leave extra processes running.
Move them to their own directory until these issues are sorted. Note
that this means that the tests will not be run in CI. Like the inspector
tests and other tests, they will have to be run manually when they are
wanted.
PR-URL: https://github.com/nodejs/node/pull/9506
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Reviewed-By: Matthew Loring <mattloring@google.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Line breaks on Windows should be CRLF, but Node also supports LF.
Hence, do not check line breaks on Windows, when running
vcbuild jslint.
Fixes: https://github.com/nodejs/node/issues/6912
PR-URL: https://github.com/nodejs/node/pull/8785
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Enable the cctests on the CI now that they know how to write TAP output.
PR-URL: https://github.com/nodejs/node/pull/8034
Reviewed-By: James M Snell <jasnell@gmail.com>
This test executes a simple debug session over the inspector protocol.
PR-URL: https://github.com/nodejs/node/pull/8429
Reviewed-By: ofrobots - Ali Ijaz Sheikh <ofrobots@google.com>
The RELEASE_URLBASE environment variable is used in releases as
a prefix for links in the process.release object. The Makefile picks
it and forwards it to configure, but vcbuild.bat did not. Hence, in
Windows, Node releases have a correct process.release because it uses
the default URL, but nightlies, RCs and so on do not, breaking
node-gyp. This enables native modules to be built with such versions
of Node.
PR-URL: https://github.com/nodejs/node/pull/8430
Reviewed-By: jbergstroem - Johan Bergström <bugs@bergstroem.nu>
Benjamin Coe
Nikolai Vavilov
Gibson Fahnestock
Bartosz Sosnowski
Refael Ackermann
Richard Lau
Daniel Bevenius
Anna Henningsen
James M Snell
Jason Ginchereau
Kunal Pathak
Kyle Farnung
João Reis
Rich Trott
Roman Reiss
Tony Rice
Brian White
Vse Mozhet Byt
Sam Roberts
Sebastian Van Sande
Morgan Brenner
liusi
Jan Krems
Ben Noordhuis
Joe Doyle
Rod Vagg
Eugene Ostroukhov