doc: replace to Node.js

PR-URL: #19056
Reviewed-By: Matheus Marchini <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Shingo Inoue <[email protected]>

Author: hiroppy

doc/api/cli.md

@@ -452,8 +452,8 @@ added: v8.0.0
 
 A space-separated list of command line options. `options...` are interpreted as
 if they had been specified on the command line before the actual command line
-(so they can be overridden).  Node will exit with an error if an option that is
-not allowed in the environment is used, such as `-p` or a script file.
+(so they can be overridden). Node.js will exit with an error if an option
+that is not allowed in the environment is used, such as `-p` or a script file.
 
 Node options that are allowed are:
 - `--enable-fips`

doc/api/deprecations.md

@@ -610,7 +610,7 @@ a V8-inspector based CLI debugger available through `node inspect`.
 
 Type: End-of-Life
 
-DebugContext has been removed in V8 and is not available in Node 10+.
+DebugContext has been removed in V8 and is not available in Node.js 10+.
 
 DebugContext was an experimental API.
 

doc/api/documentation.md

@@ -80,7 +80,8 @@ wish to do programmatic things with the documentation.
 ## Syscalls and man pages
 
 System calls like open(2) and read(2) define the interface between user programs
-and the underlying operating system. Node functions which simply wrap a syscall,
+and the underlying operating system. Node.js functions
+which simply wrap a syscall,
 like [`fs.open()`][], will document that. The docs link to the corresponding man
 pages (short for manual pages) which describe how the syscalls work.
 

doc/api/domain.md

@@ -443,7 +443,7 @@ than crashing the program.
 
 ## Domains and Promises
 
-As of Node 8.0.0, the handlers of Promises are run inside the domain in
+As of Node.js 8.0.0, the handlers of Promises are run inside the domain in
 which the call to `.then` or `.catch` itself was made:
 
 ```js

doc/api/esm.md

@@ -106,7 +106,7 @@ fs.readFile('./foo.txt', (err, body) => {
 <!-- type=misc -->
 
 To customize the default module resolution, loader hooks can optionally be
-provided via a `--loader ./loader-name.mjs` argument to Node.
+provided via a `--loader ./loader-name.mjs` argument to Node.js.
 
 When hooks are used they only apply to ES module loading and not to any
 CommonJS modules loaded.
@@ -150,7 +150,7 @@ module. This can be one of the following:
 | `"dynamic"` | Use a [dynamic instantiate hook][] |
 
 For example, a dummy loader to load JavaScript restricted to browser resolution
-rules with only JS file extension and Node builtin modules support could
+rules with only JS file extension and Node.js builtin modules support could
 be written:
 
 ```js

doc/api/fs.md

@@ -600,7 +600,7 @@ The times in the stat object have the following semantics:
   set to an earlier value than the current `birthtime` using the
   utimes(2) system call.
 
-Prior to Node v0.12, the `ctime` held the `birthtime` on Windows
+Prior to Node.js v0.12, the `ctime` held the `birthtime` on Windows
 systems.  Note that as of v0.12, `ctime` is not "creation time", and
 on Unix systems, it never was.
 
@@ -657,7 +657,8 @@ changes:
     pr-url: https://github.com/nodejs/node/pull/6534
     description: The constants like `fs.R_OK`, etc which were present directly
                  on `fs` were moved into `fs.constants` as a soft deprecation.
-                 Thus for Node `< v6.3.0` use `fs` to access those constants, or
+                 Thus for Node.js `< v6.3.0` use `fs`
+                 to access those constants, or
                  do something like `(fs.constants || fs).R_OK` to work with all
                  versions.
 -->

doc/api/n-api.md

@@ -3489,7 +3489,7 @@ napi_status napi_get_node_version(napi_env env,
 ```
 
 - `[in] env`: The environment that the API is invoked under.
-- `[out] version`: A pointer to version information for Node itself.
+- `[out] version`: A pointer to version information for Node.js itself.
 
 Returns `napi_ok` if the API succeeded.
 

doc/api/tracing.md

@@ -3,7 +3,7 @@
 <!--introduced_in=v7.7.0-->
 
 Trace Event provides a mechanism to centralize tracing information generated by
-V8, Node core, and userspace code.
+V8, Node.js core, and userspace code.
 
 Tracing can be enabled by passing the `--trace-events-enabled` flag when
 starting a Node.js application.
@@ -42,8 +42,9 @@ string that supports `${rotation}` and `${pid}`. For example:
 node --trace-events-enabled --trace-event-file-pattern '${pid}-${rotation}.log' server.js
 ```
 
-Starting with Node 10.0.0, the tracing system uses the same time source as the
-one used by `process.hrtime()` however the trace-event timestamps are expressed
-in microseconds, unlike `process.hrtime()` which returns nanoseconds.
+Starting with Node.js 10.0.0, the tracing system uses the same time source
+as the one used by `process.hrtime()`
+however the trace-event timestamps are expressed in microseconds,
+unlike `process.hrtime()` which returns nanoseconds.
 
 [Performance API]: perf_hooks.html

doc/api/zlib.md

@@ -156,7 +156,7 @@ decompressed result is valid.
 
 <!--type=misc-->
 
-From `zlib/zconf.h`, modified to node.js's usage:
+From `zlib/zconf.h`, modified to Node.js's usage:
 
 The memory requirements for deflate are (in bytes):
 

doc/guides/building-node-with-ninja.md

@@ -1,10 +1,10 @@
-# Building Node with Ninja
+# Building Node.js with Ninja
 
 The purpose of this guide is to show how to build Node.js using [Ninja][], as
 doing so can be significantly quicker than using `make`. Please see
 [Ninja's site][Ninja] for installation instructions (unix only).
 
-To build Node with ninja, there are 3 steps that must be taken:
+To build Node.js with ninja, there are 3 steps that must be taken:
 
 1. Configure the project's OS-based build rules via `./configure --ninja`.
 2. Run `ninja -C out/Release` to produce a compiled release binary.
@@ -27,7 +27,7 @@ compile much faster than even `make -j4` (or
 ## Considerations
 
 Ninja builds vary slightly from `make` builds. If you wish to run `make test`
-after, `make` will likely still need to rebuild some amount of Node.
+after, `make` will likely still need to rebuild some amount of Node.js.
 
 As such, if you wish to run the tests, it can be helpful to invoke the test
 runner directly, like so:

doc/guides/node-postmortem-support.md

@@ -2,18 +2,18 @@
 
 Postmortem metadata are constants present in the final build which can be used
 by debuggers and other tools to navigate through internal structures of software
-when analyzing its memory (either on a running process or a core dump). Node
-provides this metadata in its builds for V8 and Node internal structures.
+when analyzing its memory (either on a running process or a core dump). Node.js
+provides this metadata in its builds for V8 and Node.js internal structures.
 
 
 ### V8 Postmortem metadata
 
 V8 prefixes all postmortem constants with `v8dbg_`, and they allow inspection of
 objects on the heap as well as object properties and references. V8 generates
 those symbols with a script (`deps/v8/tools/gen-postmortem-metadata.py`), and
-Node always includes these constants in the final build.
+Node.js always includes these constants in the final build.
 
-### Node Debug Symbols
+### Node.js Debug Symbols
 
 Node prefixes all postmortem constants with `nodedbg_`, and they complement V8
 constants by providing ways to inspect Node-specific structures, like
@@ -24,8 +24,9 @@ time.
 
 #### Calculating offset of class members
 
-Node constants referring to the offset of class members in memory are calculated
-at compile time. Because of that, those class members must be at a fixed offset
+Node.js constants referring to the offset of class members in memory
+are calculated at compile time.
+Because of that, those class members must be at a fixed offset
 from the start of the class. That's not a problem in most cases, but it also
 means that those members should always come after any templated member on the
 class definition.

doc/guides/writing-tests.md

@@ -365,7 +365,7 @@ The test can be executed by running the `cctest` target:
 $ make cctest
 ```
 
-### Node test fixture
+### Node.js test fixture
 There is a [test fixture][] named `node_test_fixture.h` which can be included by
 unit tests. The fixture takes care of setting up the Node.js environment
 and tearing it down after the tests have finished.

tools/icu/README.md

@@ -20,9 +20,9 @@ internationalization functionality.
 
 ## How to upgrade ICU
 
-- Make sure your node workspace is clean (clean `git status`) should be
+- Make sure your Node.js workspace is clean (clean `git status`) should be
   sufficient.
-- Configure Node with the specific [ICU version](http://icu-project.org/download)
+- Configure Node.js with the specific [ICU version](http://icu-project.org/download)
   you want to upgrade to, for example:
 
 ```shell
@@ -40,7 +40,7 @@ make
   - Specifically, look for the lists in `sources!` in the `icu-generic.gyp` for
   files to exclude.
 
-- Verify the node build works:
+- Verify the Node.js build works:
 
 ```shell
 make test-ci
@@ -62,7 +62,7 @@ new Intl.DateTimeFormat('es', {month: 'long'}).format(new Date(9E8));
 python tools/icu/shrink-icu-src.py
 ```
 
-- Now, do a clean rebuild of node to test:
+- Now, do a clean rebuild of Node.js to test:
 
 ```shell
 make -k distclean
@@ -84,7 +84,7 @@ new Intl.DateTimeFormat('es', {month: 'long'}).format(new Date(9E8));
 You are ready to check in the updated `deps/small-icu`. This is a big commit,
 so make this a separate commit from the smaller changes.
 
-- Now, rebuild the Node license.
+- Now, rebuild the Node.js license.
 
 ```shell
 # clean up - remove deps/icu
@@ -116,7 +116,7 @@ make test-ci
 
 ## Postscript about the tools
 
-The files in this directory were written for the node.js effort.
+The files in this directory were written for the Node.js effort.
 It was the intent of their author (Steven R. Loomis / srl295) to
 merge them upstream into ICU, pending much discussion within the
 ICU-TC.
@@ -125,7 +125,7 @@ ICU-TC.
 configuration file for the `icutrim.py` script. `icutrim.py` and
 `iculslocs.cpp` may themselves be superseded by components built into
 ICU in the future. As of this writing, however, the tools are separate
-entities within Node, although theyare being scrutinized by interested
+entities within Node.js, although theyare being scrutinized by interested
 members of the ICU-TC. The “upstream” ICU bugs are given below.
 
    * [#10919](http://bugs.icu-project.org/trac/ticket/10919)