doc: fix typos
PR-URL: https://github.com/nodejs/node/pull/47685 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Debadree Chatterjee <debadree333@gmail.com> Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
This commit is contained in:
parent
c6279690be
commit
32e478d7c3
@ -269,7 +269,7 @@ the path specified by `--snapshot-blob`.
|
||||
```console
|
||||
$ echo "globalThis.foo = 'I am from the snapshot'" > snapshot.js
|
||||
|
||||
# Run snapshot.js to intialize the application and snapshot the
|
||||
# Run snapshot.js to initialize the application and snapshot the
|
||||
# state of it into snapshot.blob.
|
||||
$ node --snapshot-blob snapshot.blob --build-snapshot snapshot.js
|
||||
|
||||
|
@ -567,7 +567,7 @@ applied to transform the message data before it becomes the context value for
|
||||
the store. The prior storage context is accessible from within the transform
|
||||
function in cases where context linking is required.
|
||||
|
||||
The context applied to the store should be accesible in any async code which
|
||||
The context applied to the store should be accessible in any async code which
|
||||
continues from execution which began during the given function, however
|
||||
there are some situations in which [context loss][] may occur.
|
||||
|
||||
@ -956,7 +956,7 @@ channels.asyncStart.bindStore(myStore, (data) => {
|
||||
|
||||
A TracingChannel is a collection of several diagnostics\_channels representing
|
||||
specific points in the execution lifecycle of a single traceable action. The
|
||||
behaviour is split into five diagnostics\_channels consisting of `start`,
|
||||
behavior is split into five diagnostics\_channels consisting of `start`,
|
||||
`end`, `asyncStart`, `asyncEnd`, and `error`. A single traceable action will
|
||||
share the same event object between all events, this can be helpful for
|
||||
managing correlation through a weakmap.
|
||||
|
@ -212,7 +212,7 @@ If domains are in use, then all **new** `EventEmitter` objects (including
|
||||
Stream objects, requests, responses, etc.) will be implicitly bound to
|
||||
the active domain at the time of their creation.
|
||||
|
||||
Additionally, callbacks passed to lowlevel event loop requests (such as
|
||||
Additionally, callbacks passed to low-level event loop requests (such as
|
||||
to `fs.open()`, or other callback-taking methods) will automatically be
|
||||
bound to the active domain. If they throw, then the domain will catch
|
||||
the error.
|
||||
@ -409,7 +409,7 @@ specified emitter.
|
||||
* `...args` {any}
|
||||
|
||||
Run the supplied function in the context of the domain, implicitly
|
||||
binding all event emitters, timers, and lowlevel requests that are
|
||||
binding all event emitters, timers, and low-level requests that are
|
||||
created in that context. Optionally, arguments can be passed to
|
||||
the function.
|
||||
|
||||
|
@ -54,7 +54,7 @@ Create a new instance of the `inspector.Session` class. The inspector session
|
||||
needs to be connected through [`session.connect()`][] before the messages
|
||||
can be dispatched to the inspector backend.
|
||||
|
||||
When using `Session`, the object outputed by the console API will not be
|
||||
When using `Session`, the object outputted by the console API will not be
|
||||
released, unless we performed manually `Runtime.DiscardConsoleEntries`
|
||||
command.
|
||||
|
||||
@ -227,7 +227,7 @@ Create a new instance of the `inspector.Session` class. The inspector session
|
||||
needs to be connected through [`session.connect()`][] before the messages
|
||||
can be dispatched to the inspector backend.
|
||||
|
||||
When using `Session`, the object outputed by the console API will not be
|
||||
When using `Session`, the object outputted by the console API will not be
|
||||
released, unless we performed manually `Runtime.DiscardConsoleEntries`
|
||||
command.
|
||||
|
||||
|
@ -37,7 +37,7 @@ Node-API is a C API that ensures ABI stability across Node.js versions
|
||||
and different compiler levels. A C++ API can be easier to use.
|
||||
To support using C++, the project maintains a
|
||||
C++ wrapper module called [`node-addon-api`][].
|
||||
This wrapper provides an inlineable C++ API. Binaries built
|
||||
This wrapper provides an inlinable C++ API. Binaries built
|
||||
with `node-addon-api` will depend on the symbols for the Node-API C-based
|
||||
functions exported by Node.js. `node-addon-api` is a more
|
||||
efficient way to write code that calls Node-API. Take, for example, the
|
||||
@ -542,7 +542,7 @@ the call will succeed and `data` will be set to `NULL`.
|
||||
|
||||
## Basic Node-API data types
|
||||
|
||||
Node-API exposes the following fundamental datatypes as abstractions that are
|
||||
Node-API exposes the following fundamental data types as abstractions that are
|
||||
consumed by the various APIs. These APIs should be treated as opaque,
|
||||
introspectable only with other Node-API calls.
|
||||
|
||||
|
@ -1481,7 +1481,7 @@ console.log(values, positionals);
|
||||
|
||||
### `parseArgs` `tokens`
|
||||
|
||||
Detailed parse information is available for adding custom behaviours by
|
||||
Detailed parse information is available for adding custom behaviors by
|
||||
specifying `tokens: true` in the configuration.
|
||||
The returned tokens have properties describing:
|
||||
|
||||
|
@ -141,7 +141,7 @@ changes:
|
||||
the real paths to those directories on the host machine.
|
||||
* `returnOnExit` {boolean} By default, when WASI applications call
|
||||
`__wasi_proc_exit()` `wasi.start()` will return with the exit code
|
||||
specified rather than terminatng the process. Setting this option to
|
||||
specified rather than terminating the process. Setting this option to
|
||||
`false` will cause the Node.js process to exit with the specified
|
||||
exit code instead. **Default:** `true`.
|
||||
* `stdin` {integer} The file descriptor used as standard input in the
|
||||
|
@ -1011,7 +1011,7 @@ changes:
|
||||
* `stackSizeMb` {number} The default maximum stack size for the thread.
|
||||
Small values may lead to unusable Worker instances. **Default:** `4`.
|
||||
* `name` {string} An optional `name` to be appended to the worker title
|
||||
for debuggin/identification purposes, making the final title as
|
||||
for debugging/identification purposes, making the final title as
|
||||
`[worker ${id}] ${name}`. **Default:** `''`.
|
||||
|
||||
### Event: `'error'`
|
||||
|
@ -3,7 +3,7 @@
|
||||
Node.js uses [V8](https://v8.dev/) as its JavaScript engine.
|
||||
Embedding functions implemented in C++ incur a high overhead, so V8
|
||||
provides an API to implement native functions which may be invoked directly
|
||||
from JITted code. These functions also come with additional constraints,
|
||||
from JIT-ed code. These functions also come with additional constraints,
|
||||
for example, they may not trigger garbage collection.
|
||||
|
||||
## Limitations
|
||||
|
@ -251,8 +251,8 @@ the new tooling.
|
||||
This method is responsible for parsing the `<--YAML snippets -->` and
|
||||
transforming them into HTML elements.
|
||||
|
||||
It follows a certain kind of "schema" that basically constitues in the following
|
||||
options:
|
||||
It follows a certain kind of "schema" that basically constitutes in the
|
||||
following options:
|
||||
|
||||
| YAML Key | Description | Example | Example Result | Available on new tooling |
|
||||
| ------------- | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | --------------------------- | ------------------------ |
|
||||
|
@ -47,7 +47,7 @@ with the output being:
|
||||
user1@minikube1:~/valgrind/node-addon-examples/1_hello_world/napi$ valgrind node test.js
|
||||
==28993== Memcheck, a memory error detector
|
||||
==28993== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
|
||||
==28993== Using valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
|
||||
==28993== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
|
||||
==28993== Command: node test.js
|
||||
==28993==
|
||||
==28993== Use of uninitialised value of size 8
|
||||
@ -139,7 +139,7 @@ Running Valgrind on this code shows the following:
|
||||
user1@minikube1:~/valgrind/node-addon-examples/1_hello_world/napi$ valgrind node hello.js
|
||||
==1504== Memcheck, a memory error detector
|
||||
==1504== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
|
||||
==1504== Using V#algrind-3.13.0 and LibVEX; rerun with -h for copyright info
|
||||
==1504== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
|
||||
==1504== Command: node hello.js
|
||||
==1504==
|
||||
==1504== Use of uninitialised value of size 8
|
||||
|
@ -22,7 +22,7 @@ inclusion in the `deps_files` entry in
|
||||
The two different versions of lexer.js are maintained in the
|
||||
[nodejs/cjs-module-lexer][] project.
|
||||
|
||||
In order to update the Node.js dependencies to use to a newer verion
|
||||
In order to update the Node.js dependencies to use to a newer version
|
||||
of cjs-module-lexer, complete the following steps:
|
||||
|
||||
* Clone [nodejs/cjs-module-lexer][]
|
||||
|
@ -90,12 +90,12 @@ can be added by:
|
||||
the new option by running `./configure --help`.
|
||||
|
||||
* adding a call to `AddExternalizedBuiltin` to the constructor
|
||||
for BuildinLoader in `src/node_builtins.cc` for the
|
||||
for BuiltinLoader in `src/node_builtins.cc` for the
|
||||
dependency using the `NODE_SHARED_BUILTLIN` #define generated for
|
||||
the dependency. After running `./configure` with the new
|
||||
option you can find the #define in `config.gypi`. You can cut and
|
||||
paste one of the existing entries and then update to match the
|
||||
inport name for the dependency and the #define generated.
|
||||
import name for the dependency and the #define generated.
|
||||
|
||||
## Supporting non-externalized dependencies with JavaScript code
|
||||
|
||||
|
@ -79,7 +79,7 @@ Some additional specifics around the current approach include:
|
||||
the ability to provide different configurations for user-defined
|
||||
conditions.
|
||||
* There is no plan to define a default tsconfig.json for all Node.js users
|
||||
* We don't have consensus on provding an opinionated default but
|
||||
* We don't have consensus on providing an opinionated default but
|
||||
that should be explored after the initial steps are complete.
|
||||
* It will be important that as part of the messaging around this
|
||||
functionality that we avoid confusion that could lead people to ship
|
||||
|
@ -230,7 +230,7 @@ $ git push upstream v1.x-staging
|
||||
<summary>Security release</summary>
|
||||
|
||||
Security releases with private patches need to be prepared in the `nodejs-private`
|
||||
GitHub organisation.
|
||||
GitHub organization.
|
||||
|
||||
Add the `nodejs-private` remote:
|
||||
|
||||
@ -252,7 +252,7 @@ The list of patches to include should be listed in the "Next Security Release"
|
||||
issue in `nodejs-private`. Ask the security release steward if you're unsure.
|
||||
|
||||
The `git node land` tool does not work with the `nodejs-private`
|
||||
organisation. To land a PR in Node.js private, use `git cherry-pick` to apply
|
||||
organization. To land a PR in Node.js private, use `git cherry-pick` to apply
|
||||
each commit from the PR. You will also need to manually apply the PR
|
||||
metadata (`PR-URL`, `Reviewed-by`, etc.) by amending the commit messages. If
|
||||
known, additionally include `CVE-ID: CVE-XXXX-XXXXX` in the commit metadata.
|
||||
@ -373,7 +373,7 @@ all.
|
||||
|
||||
For security releases, it is necessary to include more detailed information
|
||||
including which vulnerabilities have been fixed, and any revert flags or
|
||||
workarounds to revert to the old behaviour.
|
||||
workarounds to revert to the old behavior.
|
||||
|
||||
You can use the following template as a guide:
|
||||
|
||||
@ -751,7 +751,7 @@ $ git push upstream v1.x-staging
|
||||
<summary>Security release</summary>
|
||||
|
||||
For security releases, you can start merging the release in the `nodejs-private`
|
||||
GitHub organisation in advance by following the same steps:
|
||||
GitHub organization in advance by following the same steps:
|
||||
|
||||
```console
|
||||
$ git checkout v1.x
|
||||
|
@ -292,7 +292,7 @@ module, you can use the `--filter` option:_
|
||||
--no-progress don't show benchmark progress indicator
|
||||
```
|
||||
|
||||
For analysing the benchmark results, use [node-benchmark-compare][] or the R
|
||||
For analyzing the benchmark results, use [node-benchmark-compare][] or the R
|
||||
script `benchmark/compare.R`.
|
||||
|
||||
```console
|
||||
|
Loading…
x
Reference in New Issue
Block a user