doc: fix typos

PR-URL: #42146
Reviewed-By: Geoffrey Booth <[email protected]>
Reviewed-By: Benjamin Gruenbaum <[email protected]>
Reviewed-By: Colin Ihrig <[email protected]>
Reviewed-By: Mohammed Keyvanzadeh <[email protected]>
Reviewed-By: Danielle Adams <[email protected]>
Reviewed-By: Mestery <[email protected]>
Reviewed-By: Jacob Smith <[email protected]>
Reviewed-By: Darshan Sen <[email protected]>
Reviewed-By: Tobias Nießen <[email protected]>
Reviewed-By: Luigi Pinca <[email protected]>
Reviewed-By: Akhil Marsonya <[email protected]>

Author: apeltop

doc/api/esm.md

@@ -1003,7 +1003,7 @@ prints the current version of CoffeeScript per the module at the URL in
 
 Sources that are in formats Node.js doesn’t understand can be converted into
 JavaScript using the [`load` hook][load hook]. Before that hook gets called,
-however, a [`resolve` hook][resolve hook] hook needs to tell Node.js not to
+however, a [`resolve` hook][resolve hook] needs to tell Node.js not to
 throw an error on unknown file types.
 
 This is less performant than transpiling source files before running

doc/api/perf_hooks.md

@@ -1058,7 +1058,7 @@ Returns the value at the given percentile.
 added: v17.4.0
 -->
 
-* `percentile` {number} A percentile value in the range (0, 100).
+* `percentile` {number} A percentile value in the range (0, 100].
 * Returns: {bigint}
 
 Returns the value at the given percentile.

doc/api/process.md

@@ -3533,7 +3533,7 @@ Synchronous writes avoid problems such as output written with `console.log()` or
 _**Warning**_: Synchronous writes block the event loop until the write has
 completed. This can be near instantaneous in the case of output to a file, but
 under high system load, pipes that are not being read at the receiving end, or
-with slow terminals or file systems, its possible for the event loop to be
+with slow terminals or file systems, it's possible for the event loop to be
 blocked often enough and long enough to have severe negative performance
 impacts. This may not be a problem when writing to an interactive terminal
 session, but consider this particularly careful when doing production logging to

doc/api/readline.md

@@ -1323,7 +1323,7 @@ const { createInterface } = require('readline');
   </tr>
   <tr>
     <td><kbd>Ctrl</kbd>+<kbd>E</kbd></td>
-    <td>Go to to end of line</td>
+    <td>Go to end of line</td>
     <td></td>
   </tr>
   <tr>

doc/api/tls.md

@@ -228,7 +228,7 @@ To use session tickets across server restarts or load balancers, servers must
 all have the same ticket keys. There are three 16-byte keys internally, but the
 tls API exposes them as a single 48-byte buffer for convenience.
 
-Its possible to get the ticket keys by calling [`server.getTicketKeys()`][] on
+It's possible to get the ticket keys by calling [`server.getTicketKeys()`][] on
 one server instance and then distribute them, but it is more reasonable to
 securely generate 48 bytes of secure random data and set them with the
 `ticketKeys` option of [`tls.createServer()`][]. The keys should be regularly

doc/api/vm.md

@@ -1047,7 +1047,7 @@ current V8 isolate, or the main context.
 * `options` {Object} Optional.
   * `mode` {string} Either `'summary'` or `'detailed'`. In summary mode,
     only the memory measured for the main context will be returned. In
-    detailed mode, the measure measured for all contexts known to the
+    detailed mode, the memory measured for all contexts known to the
     current V8 isolate will be returned.
     **Default:** `'summary'`
   * `execution` {string} Either `'default'` or `'eager'`. With default

doc/api/zlib.md

@@ -117,7 +117,7 @@ for (let i = 0; i < 30000; ++i) {
 
 In the preceding example, 30,000 deflate instances are created concurrently.
 Because of how some operating systems handle memory allocation and
-deallocation, this may lead to to significant memory fragmentation.
+deallocation, this may lead to significant memory fragmentation.
 
 It is strongly recommended that the results of compression
 operations be cached to avoid duplication of effort.

doc/contributing/maintaining-openssl.md

@@ -25,7 +25,7 @@ Details on the fork, as well as the latest sources, can be found at
 <https://github.com/quictls/openssl>.
 
 Branches are used per OpenSSL version (for instance,
-<https://github.com/quictls/openssl/tree/OpenSSL_1_1_1j+quic)>.
+<https://github.com/quictls/openssl/tree/OpenSSL_1_1_1j+quic>).
 
 ## Requirements
 

doc/contributing/pull-requests.md

@@ -437,7 +437,7 @@ check with the contributor to see if they intend to continue the work before
 checking if they would mind if you took it over (especially if it just has
 nits left). When doing so, it is courteous to give the original contributor
 credit for the work they started (either by preserving their name and email
-address in the commit log, or by using an `Author:` meta-data tag in the
+address) in the commit log, or by using an `Author:` meta-data tag in the
 commit.
 
 ### Approving a change

doc/contributing/static-analysis.md

@@ -13,4 +13,4 @@ titled `Please add me to coverity`. A member of the build WG with admin
 access will verify that the requestor is an existing collaborator as listed in
 the [collaborators section](https://github.com/nodejs/node#collaborators)
 on the nodejs/node project repo. Once validated the requestor will added
-to to the coverity project.
+to the coverity project.