Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Aviv Keller <me@aviv.sh>
Signed-off-by: Aviv Keller <me@aviv.sh>

Author: avivkeller

pages/napi/build-tools/cmake-js.md

@@ -47,7 +47,7 @@ Since your native module needs to be compiled using CMake.js on installation, th
 
 ```json
   "scripts": {
-    "install": "cmake-js compile",
+    "install": "cmake-js compile"
   }
 ```
 

pages/napi/getting-started/migration.md

@@ -73,7 +73,7 @@ The conversion tool cannot anticipate every coding situation. So there will typi
 
 ### Cannot find module 'nan'
 
-This error, and its counterpart where `napi.h` cannot be found, is due to code missing in the `bind.gyp` file. For this project, you'll see this code in the binding.gyp:
+This error, and its counterpart where `napi.h` cannot be found, is due to code missing in the `binding.gyp` file. For this project, you'll see this code in the binding.gyp:
 
 ```json
 'include_dirs' : [ '<!(node -e "require(\'nan\')")' ]

pages/napi/getting-started/objectwrap.md

@@ -36,7 +36,7 @@ npm test
 
 ## binding.gyp
 
-The project's [**binding.gyp**](https://github.com/nodejs/node-addon-examples/blob/main/src/2-js-to-native-conversion/object-wrap-demo/node-addon-api/binding.gyp) follows the standard format (see [Anatomy of a Node-API project](/learn/napi/getting-started/project-structure.md#bindinggypjs) for a full explanation of the `binding.gyp` format and how `node-gyp` uses it).
+The project's [**binding.gyp**](https://github.com/nodejs/node-addon-examples/blob/main/src/2-js-to-native-conversion/object-wrap-demo/node-addon-api/binding.gyp) follows the standard format (see [Anatomy of a Node-API project](/learn/napi/getting-started/project-structure.md#bindinggyp) for a full explanation of the `binding.gyp` format and how `node-gyp` uses it).
 
 ## src/object_wrap_demo.h and src/object_wrap_demo.cc
 

pages/napi/index.md

@@ -4,7 +4,7 @@ authors: gabrielschulhof, NickNaso, jschlight, mhdawson, KevinEady, avivkeller
 
 # Node-API
 
-[Node-API](https://nodejs.org/api/n-api.html) is a stable C API built into Node.js that lets C/C++ code create, read, and manipulate JavaScript values as if they were created by JavaScript itself. It was introduced experimentally in Node.js 8.0.0 and became stable (no longer behind a flag) in Node.js 12.
+[Node-API](https://nodejs.org/api/n-api.html) is a stable C API built into Node.js that lets C/C++ code create, read, and manipulate JavaScript values as if they were created by JavaScript itself. It was introduced experimentally in Node.js 8.0.0 and became stable (no longer behind a flag) in the Node.js 8/10 timeframe.
 
 Because Node-API is part of Node.js itself, it requires no additional installation.
 

pages/napi/special-topics/asyncworker.md

@@ -4,7 +4,7 @@ authors: gabrielschulhof, NickNaso, jschlight, mhdawson, KevinEady, avivkeller
 
 # AsyncWorker
 
-You may have a project in which you have a piece of long-running C/C++ code that you want run in the background instead of on Node's main event loop. Node-API's [`AsyncWorker`](https://github.com/nodejs/node-addon-api/blob/main/doc/async_worker.md) class is designed specifically for this case.
+You may have a project in which you have a piece of long-running C/C++ code that you want to run in the background instead of on Node's main event loop. Node-API's [`AsyncWorker`](https://github.com/nodejs/node-addon-api/blob/main/doc/async_worker.md) class is designed specifically for this case.
 
 As a programmer, your job is essentially to subclass `AsyncWorker` and to implement the `Execute` method. You'll also probably implement a wrapper function to make using your `AsyncWorker` easier.
 

pages/napi/special-topics/context-awareness.md

@@ -4,7 +4,7 @@ authors: gabrielschulhof, NickNaso, jschlight, mhdawson, KevinEady, avivkeller
 
 # Context Awareness
 
-Node.js has historically run as a single-threaded process. This all changed with the introduction of [Worker Threads](https://nodejs.org/api/worker_threads.html#worker_threads_worker_threads) in Node 10. Worker Threads add a JavaScript-friendly concurrency abstraction that native add-on developers need to be aware of. What this means practically is that your native add-on may be loaded and unloaded more than once and its code may be executed concurrently in multiple threads. There are specific steps you must take to insure your native add-on code runs correctly.
+Node.js has historically run as a single-threaded process. This all changed with the introduction of [Worker Threads](https://nodejs.org/api/worker_threads.html#worker_threads_worker_threads) in Node 10. Worker Threads add a JavaScript-friendly concurrency abstraction that native add-on developers need to be aware of. What this means practically is that your native add-on may be loaded and unloaded more than once and its code may be executed concurrently in multiple threads. There are specific steps you must take to ensure your native add-on code runs correctly.
 
 The Worker Thread model specifies that each Worker runs completely independently of each other and communicate to the parent Worker using a MessagePort object supplied by the parent. This makes the Worker Threads essentially isolated from one another. The same is true for your native add-on.
 
@@ -20,9 +20,9 @@ The next sections describe two different techniques you can use to allocate and
 
 ## Instance data
 
-Node-API gives you the ability to associate a single piece of memory your native-add allocates with the context under which it is running. This technique is called "instance data" and is useful when your native add-on allocates a single piece of data when its loaded.
+Node-API gives you the ability to associate a single piece of memory your native add-on allocates with the context under which it is running. This technique is called "instance data" and is useful when your native add-on allocates a single piece of data when its loaded.
 
-The `napi_set_instance_data` allows your native add-on to associate a single piece of allocated memory with the context under which you native add-on is loaded. The `napi_get_instance_data` can then be called anywhere in you native add-on to retrieve the location of the memory that was allocated.
+The `napi_set_instance_data` allows your native add-on to associate a single piece of allocated memory with the context under which your native add-on is loaded. The `napi_get_instance_data` can then be called anywhere in you native add-on to retrieve the location of the memory that was allocated.
 
 You specify a finalizer callback in your `napi_set_instance_data` call. The finalizer callback gets called when your native add-on is released from memory and is where you should release the memory associated with this context.
 
@@ -244,7 +244,7 @@ napi_value Init(napi_env env, napi_value exports) {
     *value = i;
     napi_add_env_cleanup_hook(env, CleanupHook, value);
   }
-  return nullptr;
+  return exports;
 }
 
 }  // anonymous namespace
@@ -256,8 +256,25 @@ NAPI_MODULE(NODE_GYP_MODULE_NAME, Init)
 
 ```cjs
 'use strict';
+
 // We load the native addon.
 const addon = require('bindings')('multiple_load');
 const assert = require('assert');
 const child_process = require('child_process');
+
+assert.ok(addon);
+
+if (process.argv[2] === 'child') {
+  const childAddon = require('bindings')('multiple_load');
+  assert.ok(childAddon);
+  process.exit(0);
+}
+
+const child = child_process.fork(__filename, ['child'], {
+  stdio: 'inherit'
+});
+
+child.on('exit', (code) => {
+  assert.strictEqual(code, 0);
+});
 ```

pages/napi/special-topics/object-function-refs.md

@@ -4,23 +4,23 @@ authors: gabrielschulhof, NickNaso, jschlight, mhdawson, KevinEady, avivkeller
 
 # Object and Function References
 
-JavaScript implements a dynamic memory model. When objects are no longer being used, they are automatically deleted by the garbage collector running in the background. JavaScript maintains a reference count to objects in memory to determine whether an object is still in use or not. When the reference count goes to zero, the memory for the object becomes eligible for deletion by the garbage collector.
+JavaScript implements a dynamic memory model. When objects are no longer reachable, they become eligible for reclamation by the garbage collector running in the background.
 
-There are situations when you need to insure that objects created by your Node-API code remain allocated. In this case you need to explicitly create a reference to it. This is the purpose of the `ObjectReference` and `ObjectFunction` classes.
+There are situations when you need to ensure that objects created by your Node-API code remain allocated. In this case you need to explicitly create a reference to them. This is the purpose of the `ObjectReference` and `FunctionReference` classes.
 
 ## Persistent Reference
 
 Object and function references can be instantiated as either `Weak` or `Persistent`.
 
 A `Persistent` reference initializes the internal reference count to one which prevents reclamation of the object's memory by the garbage collector. The referenced object will remain in memory for the life of the `Persistent` reference.
 
-Using a `Persistent` reference makes sense in the case where the duration of the reference is known ahead of time. The internal reference count is decremented when the `Persistent` reference is deleted. This will make the referenced object eligible for deletion of the internal reference count goes to zero.
+Using a `Persistent` reference makes sense in the case where the duration of the reference is known ahead of time. The internal reference count is decremented when the `Persistent` reference is deleted. This will make the referenced object eligible for deletion if the internal reference count goes to zero.
 
 The most common case for using a `Persistent` reference is when you create a JavaScript class in your Node-API code and you need to insure its constructor remains allocated by the JavaScript runtime engine.
 
 ## Weak Reference
 
-For more complex implementations where multiple AsyncWorkers rely of the referenced object, it may make better sense to use a `Weak` reference which initializes the internal reference count to zero. The reference count can then be maintained using the `Reference` `Ref` and `Unref` methods.
+For more complex implementations where multiple AsyncWorkers rely on the referenced object, it may make better sense to use a `Weak` reference which initializes the internal reference count to zero. The reference count can then be maintained using the `Reference` `Ref` and `Unref` methods.
 
 The most common use case for a `Weak` reference is when your Node-API code needs to monitor when a JavaScript object you've created in your Node-API code is released by the garbage collector.
 

pages/napi/special-topics/thread-safe-functions.md

@@ -36,7 +36,7 @@ Threads may call into JavaScript via [`[Non]BlockingCall`](https://github.com/no
 
 ## Thread Management
 
-Multiple threads can utilize the thread-safe function simultaneously. The thread-safe function manages its lifecycle through counting the number of threads actively utilizing it. This number starts at the initial thread count parameter in `New()`, increased via `Acquire()`, and decreased via `Released()`. Once the number of active threads reaches zero, the thread-safe function is destroyed, running the finalizer callback on the main thread if provided.
+Multiple threads can utilize the thread-safe function simultaneously. The thread-safe function manages its lifecycle through counting the number of threads actively utilizing it. This number starts at the initial thread count parameter in `New()`, increased via `Acquire()`, and decreased via `Release()`. Once the number of active threads reaches zero, the thread-safe function is destroyed, running the finalizer callback on the main thread if provided.
 
 Here are two general approaches to using thread-safe functions within applications:
 
@@ -79,7 +79,7 @@ true
 
 ### Q: My application isn't exiting correctly. It just hangs.
 
-By default, Node will wait until a thread-safe function is finalized before cleaning up and exiting. See [Thread Management](#Thread-Management). This behavior can be changed via a call to `Unref()`, permitting Node to clean up without waiting for the thread count to reach zero. A call to `Ref()` will will return the threadsafe function to the previous exit behavior, requiring it to be `Release()`ed and/or `Abort()`ed by all threads utilizing it.
+By default, Node will wait until a thread-safe function is finalized before cleaning up and exiting. See [Thread Management](#Thread-Management). This behavior can be changed via a call to `Unref()`, permitting Node to clean up without waiting for the thread count to reach zero. A call to `Ref()` will return the threadsafe function to the previous exit behavior, requiring it to be `Release()`ed and/or `Abort()`ed by all threads utilizing it.
 
 ### Q: If a thread receives `napi_closing` from a call to `[Non]BlockingCall()`, does it still need to call `Release()`?