fixup!

Author: avivkeller

pages/napi/build-tools/index.md

@@ -19,4 +19,3 @@ There are two broad strategies for shipping a native addon:
 - [node-gyp](/learn/napi/build-tools/node-gyp.md) - the default build tool bundled with npm; uses Google's GYP format and is nearly universally supported in the Node ecosystem
 - [CMake.js](/learn/napi/build-tools/cmake-js.md) - a CMake-based alternative, well-suited for projects that already use CMake
 - [node-pre-gyp](/learn/napi/build-tools/node-pre-gyp.md) - a layer on top of node-gyp for distributing pre-built binaries via Amazon S3
-- [prebuild](/learn/napi/build-tools/prebuild.md) - an alternative pre-build tool that publishes binaries as GitHub Releases

pages/napi/build-tools/node-gyp.md

@@ -6,7 +6,7 @@ authors: gabrielschulhof, NickNaso, jschlight, mhdawson, KevinEady, avivkeller
 
 [node-gyp](https://github.com/nodejs/node-gyp) is the standard build tool for native Node.js addons and is used by the vast majority of packages in the npm ecosystem. It is actively maintained by the Node.js team. Most of the examples on this site use node-gyp to build binaries.
 
-node-gyp is based on Google's [GYP](https://gyp.gsrc.io/) build tool. GYP provides a single cross-platform configuration format for C/C++ builds. Although Google archived the upstream GYP repository, node-gyp continues to receive active development and maintenance independently.
+node-gyp is based on Google's [GYP](https://gyp.gsrc.io/) build tool. GYP provides a single cross-platform configuration format for C/C++ builds. Although Google archived the upstream GYP repository, node-gyp continues to receive active development and maintenance through [gyp-next](https://github.com/nodejs/gyp-next).
 
 > node-gyp requires **Python 3.6 or later**. Python 2 is not supported. The full list of requirements for each platform can be found in the [node-gyp installation docs](https://github.com/nodejs/node-gyp#installation).
 

pages/napi/build-tools/node-pre-gyp.md

@@ -10,8 +10,6 @@ One of the limitations of native addons is that they must be compiled for each t
 
 > Note that Node-API support was added to node-pre-gyp in version 0.8.0.
 
-> [prebuild](/learn/napi/build-tools/prebuild.md) is an alternative tool that addresses the same problem.
-
 This page describes the changes required to a Node-API addon to support node-pre-gyp.
 
 ## Amazon S3
@@ -54,14 +52,14 @@ For CI environments, prefer IAM roles or short-lived credentials rather than lon
 
 ### The `dependencies` and `devDependencies` properties
 
-The package is now published under the `@mapbox` scope. Use `aws-sdk` as a dev dependency for the upload step.
+The package is now published under the `@mapbox` scope. Use `@aws-sdk/client-s3` as a dev dependency for the upload step.
 
 ```json
 "dependencies": {
   "@mapbox/node-pre-gyp": "^1.0.0"
 },
 "devDependencies": {
-  "aws-sdk": "^2.0.0"
+  "@aws-sdk/client-s3": "^3.0.0"
 }
 ```
 

pages/napi/build-tools/prebuild.md

@@ -14,7 +14,7 @@ Each Worker Thread operates within its own environment which is also referred to
 
 If your native add-on requires persistent memory, allocating this memory in static global space is a recipe for disaster. Instead, it is _essential_ that this memory is allocated each time within the context in which the native add-on is initialized. This memory is typically allocated in your native add-on's `Init` method. But in some cases it can also be allocated as your native add-on is running.
 
-In addition to the multiple loading described above, your native add-on is also subject to automatic unloading by the JavaScript runtime engine's garbage collector when your native add-on is no longer in use. To prevent memory leaks, any memory your native add-on has allocated _must_ be freed when you native add-on is unloaded.
+In addition to the multiple loading described above, your native add-on is also subject to automatic unloading by the JavaScript runtime engine's garbage collector when your native add-on is no longer in use. To prevent memory leaks, any memory your native add-on has allocated _must_ be freed when your native add-on is unloaded.
 
 The next sections describe two different techniques you can use to allocate and free persistent memory associated with your native add-on. The techniques may be used individually or together in your native add-on.
 
@@ -224,9 +224,9 @@ The drawback is that if you need to access these allocated buffer you are respon
 
 Because keeping track of the allocated buffers is dependent upon the architecture of the native add-on, this is a trivial example showing how the buffers can be allocated and released.
 
-#### binding.c
+#### binding.cc
 
-```c
+```cpp
 #include <stdlib.h>
 #include <stdio.h>
 #include "node_api.h"