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: