Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: harmonize fenced code snippet flags
Browse files Browse the repository at this point in the history
We had a few code snippets that were using a non-descriptive tag (e.g.
`console` or `text`), whereas the actual language it's using describes
it better, and improves the syntax highlighting. This commit also
removes non-necessary leading chars (e.g. `$`, `>`, or `%`) to make it
easier for readers to copy and paste to try the command themselves.

PR-URL: nodejs#48082
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: Paolo Insogna <paolo@cowtech.it>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
aduh95 authored and fasenderos committed May 22, 2023
1 parent a1028fd commit ef913d8
Showing 23 changed files with 381 additions and 381 deletions.
196 changes: 98 additions & 98 deletions BUILDING.md

Large diffs are not rendered by default.

16 changes: 8 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
@@ -98,15 +98,15 @@ files.

To download `SHASUMS256.txt` using `curl`:

```console
$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt
```bash
curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt
```

To check that a downloaded file matches the checksum, run
it through `sha256sum` with a command such as:

```console
$ grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -
```bash
grep node-vx.y.z.tar.gz SHASUMS256.txt | sha256sum -c -
```

For Current and LTS, the GPG detached signature of `SHASUMS256.txt` is in
@@ -115,16 +115,16 @@ For Current and LTS, the GPG detached signature of `SHASUMS256.txt` is in
[the GPG keys of individuals authorized to create releases](#release-keys). To
import the keys:

```console
$ gpg --keyserver hkps://keys.openpgp.org --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
```bash
gpg --keyserver hkps://keys.openpgp.org --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
```

See [Release keys](#release-keys) for a script to import active release keys.

Next, download the `SHASUMS256.txt.sig` for the release:

```console
$ curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig
```bash
curl -O https://nodejs.org/dist/vx.y.z/SHASUMS256.txt.sig
```

Then use `gpg --verify SHASUMS256.txt.sig SHASUMS256.txt` to verify
4 changes: 2 additions & 2 deletions doc/api/addons.md
Original file line number Diff line number Diff line change
@@ -532,8 +532,8 @@ filename to the `sources` array:
Once the `binding.gyp` file is ready, the example addons can be configured and
built using `node-gyp`:

```console
$ node-gyp configure build
```bash
node-gyp configure build
```

### Function arguments
30 changes: 15 additions & 15 deletions doc/api/cli.md
Original file line number Diff line number Diff line change
@@ -184,8 +184,8 @@ Error: Access to this API has been restricted

The process needs to have access to the `index.js` module:

```console
$ node --experimental-permission --allow-fs-read=/path/to/index.js index.js
```bash
node --experimental-permission --allow-fs-read=/path/to/index.js index.js
```

### `--allow-fs-write`
@@ -314,9 +314,9 @@ added: v10.12.0

Print source-able bash completion script for Node.js.

```console
$ node --completion-bash > node_bash_completion
$ source node_bash_completion
```bash
node --completion-bash > node_bash_completion
source node_bash_completion
```

### `-C condition`, `--conditions=condition`
@@ -339,8 +339,8 @@ The default Node.js conditions of `"node"`, `"default"`, `"import"`, and

For example, to run a module with "development" resolutions:

```console
$ node -C development app.js
```bash
node -C development app.js
```

### `--cpu-prof`
@@ -1854,8 +1854,8 @@ Use `--watch-path` to specify what paths to watch.
This flag cannot be combined with
`--check`, `--eval`, `--interactive`, or the REPL.

```console
$ node --watch index.js
```bash
node --watch index.js
```

### `--watch-path`
@@ -1877,8 +1877,8 @@ combination with `--watch`.
This flag cannot be combined with
`--check`, `--eval`, `--interactive`, `--test`, or the REPL.

```console
$ node --watch-path=./src --watch-path=./tests index.js
```bash
node --watch-path=./src --watch-path=./tests index.js
```

This option is only supported on macOS and Windows.
@@ -1889,8 +1889,8 @@ when the option is used on a platform that does not support it.

Disable the clearing of the console when watch mode restarts the process.

```console
$ node --watch --watch-preserve-output test.js
```bash
node --watch --watch-preserve-output test.js
```

### `--zero-fill-buffers`
@@ -2525,8 +2525,8 @@ garbage collection in an effort to free unused memory.
On a machine with 2 GiB of memory, consider setting this to
1536 (1.5 GiB) to leave some memory for other uses and avoid swapping.

```console
$ node --max-old-space-size=1536 index.js
```bash
node --max-old-space-size=1536 index.js
```

### `--max-semi-space-size=SIZE` (in megabytes)
2 changes: 1 addition & 1 deletion doc/api/esm.md
Original file line number Diff line number Diff line change
@@ -711,7 +711,7 @@ all `import` calls. They won't apply to `require` calls; those still follow
Loaders follow the pattern of `--require`:
```console
```bash
node \
--experimental-loader unpkg \
--experimental-loader http-to-https \
8 changes: 4 additions & 4 deletions doc/api/net.md
Original file line number Diff line number Diff line change
@@ -1616,8 +1616,8 @@ server.listen(8124, () => {

Test this by using `telnet`:

```console
$ telnet localhost 8124
```bash
telnet localhost 8124
```

To listen on the socket `/tmp/echo.sock`:
@@ -1630,8 +1630,8 @@ server.listen('/tmp/echo.sock', () => {

Use `nc` to connect to a Unix domain socket server:

```console
$ nc -U /tmp/echo.sock
```bash
nc -U /tmp/echo.sock
```

## `net.getDefaultAutoSelectFamily()`
12 changes: 6 additions & 6 deletions doc/api/process.md
Original file line number Diff line number Diff line change
@@ -922,8 +922,8 @@ argv.forEach((val, index) => {

Launching the Node.js process as:

```console
$ node process-args.js one two=three four
```bash
node process-args.js one two=three four
```

Would generate the output:
@@ -1577,8 +1577,8 @@ reflected outside the Node.js process, or (unless explicitly requested)
to other [`Worker`][] threads.
In other words, the following example would not work:
```console
$ node -e 'process.env.foo = "bar"' && echo $foo
```bash
node -e 'process.env.foo = "bar"' && echo $foo
```
While the following will:
@@ -1683,8 +1683,8 @@ include the Node.js executable, the name of the script, or any options following
the script name. These options are useful in order to spawn child processes with
the same execution environment as the parent.
```console
$ node --harmony script.js --version
```bash
node --harmony script.js --version
```
Results in `process.execArgv`:
2 changes: 1 addition & 1 deletion doc/api/repl.md
Original file line number Diff line number Diff line change
@@ -712,7 +712,7 @@ terminal settings, which will allow use with `rlwrap`.

For example, the following can be added to a `.bashrc` file:

```text
```bash
alias node="env NODE_NO_READLINE=1 rlwrap node"
```

52 changes: 26 additions & 26 deletions doc/api/single-executable-applications.md
Original file line number Diff line number Diff line change
@@ -26,42 +26,42 @@ Here are the steps for creating a single executable application using one such
tool, [postject][]:

1. Create a JavaScript file:
```console
$ echo 'console.log(`Hello, ${process.argv[2]}!`);' > hello.js
```bash
echo 'console.log(`Hello, ${process.argv[2]}!`);' > hello.js
```

2. Create a configuration file building a blob that can be injected into the
single executable application (see
[Generating single executable preparation blobs][] for details):
```console
$ echo '{ "main": "hello.js", "output": "sea-prep.blob" }' > sea-config.json
```bash
echo '{ "main": "hello.js", "output": "sea-prep.blob" }' > sea-config.json
```

3. Generate the blob to be injected:
```console
$ node --experimental-sea-config sea-config.json
```bash
node --experimental-sea-config sea-config.json
```

4. Create a copy of the `node` executable and name it according to your needs:

* On systems other than Windows:

```console
$ cp $(command -v node) hello
```bash
cp $(command -v node) hello
```

* On Windows:

Using PowerShell:

```console
$ cp (Get-Command node).Source hello.exe
```bash
cp (Get-Command node).Source hello.exe
```

Using Command Prompt:

```console
$ for /F "tokens=*" %n IN ('where.exe node') DO @(copy "%n" hello.exe)
```bash
for /F "tokens=*" %n IN ('where.exe node') DO @(copy "%n" hello.exe)
```

The `.exe` extension is necessary.
@@ -70,17 +70,17 @@ tool, [postject][]:

* On macOS:

```console
$ codesign --remove-signature hello
```bash
codesign --remove-signature hello
```

* On Windows (optional):

[signtool][] can be used from the installed [Windows SDK][]. If this step is
skipped, ignore any signature-related warning from postject.

```console
$ signtool remove /s hello.exe
```bash
signtool remove /s hello.exe
```

6. Inject the blob into the copied binary by running `postject` with
@@ -100,20 +100,20 @@ tool, [postject][]:
To summarize, here is the required command for each platform:

* On Linux:
```console
$ npx postject hello NODE_SEA_BLOB sea-prep.blob \
```bash
npx postject hello NODE_SEA_BLOB sea-prep.blob \
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2
```

* On Windows:
```console
$ npx postject hello.exe NODE_SEA_BLOB sea-prep.blob \
```bash
npx postject hello.exe NODE_SEA_BLOB sea-prep.blob \
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2
```

* On macOS:
```console
$ npx postject hello NODE_SEA_BLOB sea-prep.blob \
```bash
npx postject hello NODE_SEA_BLOB sea-prep.blob \
--sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2 \
--macho-segment-name NODE_SEA
```
@@ -122,17 +122,17 @@ tool, [postject][]:

* On macOS:

```console
$ codesign --sign - hello
```bash
codesign --sign - hello
```

* On Windows (optional):

A certificate needs to be present for this to work. However, the unsigned
binary would still be runnable.

```console
$ signtool sign /fd SHA256 hello.exe
```bash
signtool sign /fd SHA256 hello.exe
```

8. Run the binary:
22 changes: 11 additions & 11 deletions doc/api/synopsis.md
Original file line number Diff line number Diff line change
@@ -29,23 +29,23 @@ Now, create an empty project folder called `projects`, then navigate into it.

Linux and Mac:

```console
$ mkdir ~/projects
$ cd ~/projects
```bash
mkdir ~/projects
cd ~/projects
```

Windows CMD:

```console
> mkdir %USERPROFILE%\projects
> cd %USERPROFILE%\projects
```powershell
mkdir %USERPROFILE%\projects
cd %USERPROFILE%\projects
```

Windows PowerShell:

```console
> mkdir $env:USERPROFILE\projects
> cd $env:USERPROFILE\projects
```powershell
mkdir $env:USERPROFILE\projects
cd $env:USERPROFILE\projects
```

Next, create a new source file in the `projects`
@@ -73,8 +73,8 @@ server.listen(port, hostname, () => {

Save the file, go back to the terminal window, and enter the following command:

```console
$ node hello-world.js
```bash
node hello-world.js
```

Output like this should appear in the terminal:
4 changes: 2 additions & 2 deletions doc/api/tls.md
Original file line number Diff line number Diff line change
@@ -285,8 +285,8 @@ failures, it is easy to not notice unnecessarily poor TLS performance. The
OpenSSL CLI can be used to verify that servers are resuming sessions. Use the
`-reconnect` option to `openssl s_client`, for example:

```console
$ openssl s_client -connect localhost:443 -reconnect
```bash
openssl s_client -connect localhost:443 -reconnect
```

Read through the debug output. The first connection should say "New", for
4 changes: 2 additions & 2 deletions doc/api/wasi.md
Original file line number Diff line number Diff line change
@@ -93,8 +93,8 @@ To run the above example, create a new WebAssembly text format file named

Use [wabt](https://github.com/WebAssembly/wabt) to compile `.wat` to `.wasm`

```console
$ wat2wasm demo.wat
```bash
wat2wasm demo.wat
```

## Class: `WASI`
52 changes: 26 additions & 26 deletions doc/contributing/collaborator-guide.md
Original file line number Diff line number Diff line change
@@ -555,9 +555,9 @@ this tool, please file an issue [to the issue tracker][node-core-utils-issues].

Quick example:

```text
$ npm install -g node-core-utils
$ git node land $PRID
```bash
npm install -g node-core-utils
git node land $PRID
```

To use `node-core-utils`, you will need a GitHub access token. If you do not
@@ -576,37 +576,37 @@ pull request rather than rely on `git-node`.

Clear any `am`/`rebase` that might already be underway:

```text
$ git am --abort
$ git rebase --abort
```bash
git am --abort
git rebase --abort
```

Checkout proper target branch:

```text
$ git checkout main
```bash
git checkout main
```

Update the tree (assumes your repository is set up as detailed in
[CONTRIBUTING.md](./pull-requests.md#step-1-fork)):

```text
$ git fetch upstream
$ git merge --ff-only upstream/main
```bash
git fetch upstream
git merge --ff-only upstream/main
```

Apply external patches:

```text
$ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
```bash
curl -L https://github.com/nodejs/node/pull/xxx.patch | git am --whitespace=fix
```

If the merge fails even though recent CI runs were successful, try a 3-way
merge:

```text
$ git am --abort
$ curl -L https://github.com/nodejs/node/pull/xxx.patch | git am -3 --whitespace=fix
```bash
git am --abort
curl -L https://github.com/nodejs/node/pull/xxx.patch | git am -3 --whitespace=fix
```

If the 3-way merge succeeds, check the results against the original pull
@@ -617,20 +617,20 @@ has landed since the CI run. You will have to ask the author to rebase.

Check and re-review the changes:

```text
$ git diff upstream/main
```bash
git diff upstream/main
```

Check the number of commits and commit messages:

```text
$ git log upstream/main...main
```bash
git log upstream/main...main
```

Squash commits and add metadata:

```text
$ git rebase -i upstream/main
```bash
git rebase -i upstream/main
```

This will open a screen like this (in the default shell editor):
@@ -706,8 +706,8 @@ precaution, run tests (`make -j4 test` or `vcbuild test`).
Confirm that the commit message format is correct using
[core-validate-commit](https://github.com/nodejs/core-validate-commit).

```text
$ git rev-list upstream/main...HEAD | xargs core-validate-commit
```bash
git rev-list upstream/main...HEAD | xargs core-validate-commit
```

Optional: For your own commits, force push the amended commit to the pull
@@ -722,8 +722,8 @@ the issue with the red closed status.

Time to push it:

```text
$ git push upstream main
```bash
git push upstream main
```

Close the pull request with a "Landed in `<commit hash>`" comment. Even if
12 changes: 6 additions & 6 deletions doc/contributing/investigating-native-memory-leaks.md
Original file line number Diff line number Diff line change
@@ -29,15 +29,15 @@ To use Valgrind:
It is an optional package in most cases and must be installed explicitly.
For example on Debian/Ubuntu:

```console
```bash
apt-get install valgrind
```

## Invocation

The simplest invocation of Valgrind is:

```console
```bash
valgrind node test.js
```

@@ -433,7 +433,7 @@ follow cover the steps needed to enable debug symbols to get more info.
To enable debug symbols for all of your addons that are compiled on
install use:

```console
```bash
npm install --debug
```

@@ -443,7 +443,7 @@ results in the addons being compiled with the debug option.
If the native addon contains pre-built binaries you will need to force
a rebuild.

```console
```bash
npm install --debug
npm rebuild
```
@@ -517,7 +517,7 @@ To get additional information with Valgrind:
* Check out the Node.js source corresponding to the release that you
want to debug. For example:
```console
```bash
git clone https://github.com/nodejs/node.git
git checkout v12.14.1
```
@@ -526,7 +526,7 @@ git checkout v12.14.1
[building a debug build](https://github.com/nodejs/node/blob/v12.14.1/BUILDING.md#building-a-debug-build)).
For example, on \*nix:
```console
```bash
./configure --debug
make -j4
```
2 changes: 1 addition & 1 deletion doc/contributing/maintaining/maintaining-V8.md
Original file line number Diff line number Diff line change
@@ -187,7 +187,7 @@ Here are the steps for the bug mentioned above:

* Download and apply the commit linked-to in the issue (in this case a51f429):

```console
```bash
curl -L https://github.com/v8/v8/commit/a51f429.patch | git am -3 --directory=deps/v8
```

42 changes: 21 additions & 21 deletions doc/contributing/maintaining/maintaining-openssl.md
Original file line number Diff line number Diff line change
@@ -61,15 +61,15 @@ release).

### OpenSSL 3.x.x

```console
% git clone https://github.com/quictls/openssl
% cd openssl
% cd ../node/deps/openssl
% rm -rf openssl
% cp -R ../../../openssl openssl
% rm -rf openssl/.git* openssl/.travis*
% git add --all openssl
% git commit openssl
```bash
git clone https://github.com/quictls/openssl
cd openssl
cd ../node/deps/openssl
rm -rf openssl
cp -R ../../../openssl openssl
rm -rf openssl/.git* openssl/.travis*
git add --all openssl
git commit openssl
```

```text
@@ -92,19 +92,19 @@ This updates all sources in deps/openssl/openssl by:
Use `make` to regenerate all platform dependent files in
`deps/openssl/config/archs/`:

```console
```bash
# On non-Linux machines
% make gen-openssl
make gen-openssl

# On Linux machines
% make -C deps/openssl/config clean
% make -C deps/openssl/config
make -C deps/openssl/config clean
make -C deps/openssl/config
```

**Note**: If the 32-bit Windows is failing to compile run this workflow instead:

```console
% make -C deps/openssl/config clean
```bash
make -C deps/openssl/config clean
# Edit deps/openssl/openssl/crypto/perlasm/x86asm.pl changing
# #ifdef to %ifdef to make it compatible to nasm on 32-bit Windows.
# See: https://github.com/nodejs/node/pull/43603#issuecomment-1170670844
@@ -117,8 +117,8 @@ Check diffs to ensure updates are right. Even if there are no updates in openssl
sources, `buildinf.h` files will be updated because they have timestamp
data in them.

```console
% git diff -- deps/openssl
```bash
git diff -- deps/openssl
```

_Note_: On Windows, OpenSSL Configure generates a `makefile` that can be
@@ -133,10 +133,10 @@ please ask @shigeki for details.
Update all architecture dependent files. Do not forget to git add or remove
files if they are changed before committing:

```console
% git add deps/openssl/config/archs
% git add deps/openssl/openssl
% git commit
```bash
git add deps/openssl/config/archs
git add deps/openssl/openssl
git commit
```

The commit message can be written as (with the openssl version set
22 changes: 11 additions & 11 deletions doc/contributing/pull-requests.md
Original file line number Diff line number Diff line change
@@ -70,7 +70,7 @@ it's time to create a fork.
Fork the project [on GitHub](https://github.com/nodejs/node) and clone your fork
locally.

```text
```bash
git clone git@github.com:username/node.git
cd node
git remote add upstream https://github.com/nodejs/node.git
@@ -79,7 +79,7 @@ git fetch upstream

Configure `git` so that it knows who you are:

```text
```bash
git config user.name "J. Random User"
git config user.email "j.random.user@example.com"
```
@@ -99,7 +99,7 @@ As a best practice to keep your development environment as organized as
possible, create local branches to work within. These should also be created
directly off of the upstream default branch.

```text
```bash
git checkout -b my-branch -t upstream/HEAD
```

@@ -147,7 +147,7 @@ as possible within individual commits. There is no limit to the number of
commits any single pull request may have, and many contributors find it easier
to review changes that are split across multiple commits.

```text
```bash
git add my/changed/files
git commit
```
@@ -217,7 +217,7 @@ As a best practice, once you have committed your changes, it is a good idea
to use `git rebase` (not `git merge`) to synchronize your work with the main
repository.

```text
```bash
git fetch upstream HEAD
git rebase FETCH_HEAD
```
@@ -239,7 +239,7 @@ later.
Before submitting your changes in a pull request, always run the full Node.js
test suite. To run the tests (including code linting) on Unix / macOS:

```text
```bash
./configure && make -j4 test
```

@@ -249,8 +249,8 @@ information, see

And on Windows:

```text
> vcbuild test
```powershell
vcbuild test
```

For some configurations, running all tests might take a long time (an hour or
@@ -263,7 +263,7 @@ Once you are sure your commits are ready to go, with passing tests and linting,
begin the process of opening a pull request by pushing your working branch to
your fork on GitHub.

```text
```bash
git push origin my-branch
```

@@ -292,7 +292,7 @@ To make changes to an existing pull request, make the changes to your local
branch, add a new commit with those changes, and push those to your fork.
GitHub will automatically update the pull request.

```text
```bash
git add my/changed/files
git commit
git push origin my-branch
@@ -301,7 +301,7 @@ git push origin my-branch
If a git conflict arises, it is necessary to synchronize your branch with other
changes that have landed upstream by using `git rebase`:

```text
```bash
git fetch upstream HEAD
git rebase FETCH_HEAD
git push --force-with-lease origin my-branch
20 changes: 10 additions & 10 deletions doc/contributing/releases-node-api.md
Original file line number Diff line number Diff line change
@@ -38,10 +38,10 @@ Node-API Working Group can be contacted best by opening up an issue on the

Checkout the staging branch locally.

```console
$ git remote update
$ git checkout main
$ git reset --hard upstream/main
```bash
git remote update
git checkout main
git reset --hard upstream/main
```

If the staging branch is not up to date relative to `main`, bring the
@@ -51,8 +51,8 @@ appropriate PRs and commits into it.

Create a new branch named `node-api-x-proposal`, off the main branch.

```console
$ git checkout -b node-api-10-proposal upstream/main
```bash
git checkout -b node-api-10-proposal upstream/main
```

### 3. Update `NAPI_VERSION`
@@ -83,7 +83,7 @@ version, the relevant commits should already include the `NAPI_EXPERIMENTAL`
define guards on the declaration of the new Node-API. Check for these guards
with:
```console
```bash
grep NAPI_EXPERIMENTAL src/js_native_api{_types,}.h src/node_api{_types,}.h
```

@@ -115,7 +115,7 @@ If this release includes runtime behavior version guards, the relevant commits
should already include `NAPI_VERSION_EXPERIMENTAL` guard for the change. Check
for these guards with:

```console
```bash
grep NAPI_VERSION_EXPERIMENTAL src/js_native_api_v8* src/node_api.cc
```

@@ -127,7 +127,7 @@ If this release includes add-on tests for the new Node-APIs, the relevant
commits should already include `NAPI_EXPERIMENTAL` definition for the tests.
Check for these definitions with:

```console
```bash
grep NAPI_EXPERIMENTAL test/node-api/*/{*.{h,c},binding.gyp} test/js-native-api/*/{*.{h,c},binding.gyp}
```

@@ -170,7 +170,7 @@ should already have documented the new behavior in a "Change History" section.
For all runtime version guards updated in Step 2, check for these definitions
with:

```console
```bash
grep NAPI_EXPERIMENTAL doc/api/n-api.md
```

202 changes: 101 additions & 101 deletions doc/contributing/releases.md

Large diffs are not rendered by default.

26 changes: 13 additions & 13 deletions doc/contributing/writing-and-running-benchmarks.md
Original file line number Diff line number Diff line change
@@ -159,8 +159,8 @@ assert/deepequal-object.js method="notDeepEqual" strict=0 size=100 n=5000: 9,734

It is possible to execute more groups by adding extra process arguments.

```console
$ node benchmark/run.js assert async_hooks
```bash
node benchmark/run.js assert async_hooks
```

#### Filtering benchmarks
@@ -263,20 +263,20 @@ First build two versions of Node.js, one from the `main` branch (here called
To run multiple compiled versions in parallel you need to copy the output of the
build: `cp ./out/Release/node ./node-main`. Check out the following example:

```console
$ git checkout main
$ ./configure && make -j4
$ cp ./out/Release/node ./node-main
```bash
git checkout main
./configure && make -j4
cp ./out/Release/node ./node-main

$ git checkout pr-5134
$ ./configure && make -j4
$ cp ./out/Release/node ./node-pr-5134
git checkout pr-5134
./configure && make -j4
cp ./out/Release/node ./node-pr-5134
```

The `compare.js` tool will then produce a csv file with the benchmark results.

```console
$ node benchmark/compare.js --old ./node-main --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
```bash
node benchmark/compare.js --old ./node-main --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
```

_Tips: there are some useful options of `benchmark/compare.js`. For example,
@@ -358,8 +358,8 @@ To do this use the `scatter.js` tool, this will run a benchmark multiple times
and generate a csv with the results. To see how to use this script,
run `node benchmark/scatter.js`.

```console
$ node benchmark/scatter.js benchmark/string_decoder/string-decoder.js > scatter.csv
```bash
node benchmark/scatter.js benchmark/string_decoder/string-decoder.js > scatter.csv
```

After generating the csv, a comparison table can be created using the
14 changes: 7 additions & 7 deletions doc/contributing/writing-tests.md
Original file line number Diff line number Diff line change
@@ -287,7 +287,7 @@ const freelist = require('node:internal/freelist');
In specific scenarios it may be useful to get a hold of `primordials` or
`internalBinding()`. You can do so using

```console
```bash
node --expose-internals -r internal/test/binding lib/fs.js
```

@@ -439,20 +439,20 @@ adding them to the `libraries` section in the cctest target.

The test can be executed by running the `cctest` target:

```console
$ make cctest
```bash
make cctest
```

A filter can be applied to run single/multiple test cases:

```console
$ make cctest GTEST_FILTER=EnvironmentTest.AtExitWithArgument
```bash
make cctest GTEST_FILTER=EnvironmentTest.AtExitWithArgument
```

`cctest` can also be run directly which can be useful when debugging:

```console
$ out/Release/cctest --gtest_filter=EnvironmentTest.AtExit\*
```bash
out/Release/cctest --gtest_filter=EnvironmentTest.AtExit\*
```

### Node.js test fixture
4 changes: 2 additions & 2 deletions test/wasi/README.md
Original file line number Diff line number Diff line change
@@ -4,6 +4,6 @@ Compile with clang and `wasm32-wasi` target. The clang version used must be
built with wasi-libc. You can specify the location for clang and the sysroot
if needed when running make:

```console
$ make CC=/usr/local/opt/llvm/bin/clang SYSROOT=/path/to/wasi-libc/sysroot
```bash
make CC=/usr/local/opt/llvm/bin/clang SYSROOT=/path/to/wasi-libc/sysroot
```
14 changes: 7 additions & 7 deletions test/wpt/README.md
Original file line number Diff line number Diff line change
@@ -34,9 +34,9 @@ See [Format of a status JSON file](#status-format) for details.
Use the [git node wpt][] command to download the WPT files into
`test/fixtures/wpt`. For example, to add URL tests:

```text
$ cd /path/to/node/project
$ git node wpt url
```bash
cd /path/to/node/project
git node wpt url
```

### 3. Create the test driver
@@ -71,14 +71,14 @@ with the WPT harness while taking the status file into account.
Run the test using `tools/test.py` and see if there are any failures.
For example, to run all the URL tests under `test/fixtures/wpt/url`:

```text
$ tools/test.py wpt/test-url
```bash
tools/test.py wpt/test-url
```

To run a specific test in WPT, for example, `url/url-searchparams.any.js`,
pass the file name as argument to the corresponding test driver:

```text
```bash
node test/wpt/test-url.js url-searchparams.any.js
```

@@ -149,7 +149,7 @@ expected failures.

## Format of a status JSON file

```text
```json
{
"something.scope.js": { // the file name
// Optional: If the requirement is not met, this test will be skipped

0 comments on commit ef913d8

Please sign in to comment.