From 5863a1c3ec360bd14de32efa4cd4af36df0d3db0 Mon Sep 17 00:00:00 2001
From: Lorenzo Zabot <lorenzozabot@gmail.com>
Date: Thu, 17 Apr 2025 15:14:02 +0200
Subject: [PATCH] Uniform usage of i.e. and e.g. across docs

---
 apps/site/pages/en/blog/npm/npm-1-0-link.md                     | 2 +-
 apps/site/pages/en/blog/release/v0.10.0.md                      | 2 +-
 .../en/blog/vulnerability/october-2023-security-releases.md     | 2 +-
 .../pages/en/learn/getting-started/nodejs-with-webassembly.md   | 2 +-
 apps/site/pages/en/learn/modules/publishing-a-package.mdx       | 2 +-
 apps/site/pages/en/learn/typescript/publishing-a-ts-package.md  | 2 +-
 apps/site/scripts/release-post/index.mjs                        | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/apps/site/pages/en/blog/npm/npm-1-0-link.md b/apps/site/pages/en/blog/npm/npm-1-0-link.md
index cf33c47f70cde..bbcf993656c1d 100644
--- a/apps/site/pages/en/blog/npm/npm-1-0-link.md
+++ b/apps/site/pages/en/blog/npm/npm-1-0-link.md
@@ -106,7 +106,7 @@ I highly doubt that a native Windows node will ever have comparable symbolic lin
 
 When there is a native windows port of Node, if that native windows port has `fs.symlink` and `fs.readlink` support that is exactly identical to the way that they work on Unix, then this should work fine.
 
-But I wouldn't hold my breath. Any bugs about this not working on a native Windows system (ie, not Cygwin) will most likely be closed with `wontfix`.
+But I wouldn't hold my breath. Any bugs about this not working on a native Windows system (i.e., not Cygwin) will most likely be closed with `wontfix`.
 
 ## <!-- aside_credit_where_credit8217s_due -->Aside: Credit where Credit’s Due
 
diff --git a/apps/site/pages/en/blog/release/v0.10.0.md b/apps/site/pages/en/blog/release/v0.10.0.md
index 78ce3018c1120..6ee6268d6a94b 100644
--- a/apps/site/pages/en/blog/release/v0.10.0.md
+++ b/apps/site/pages/en/blog/release/v0.10.0.md
@@ -156,7 +156,7 @@ http/simple.js type=buffer length=102400: <span style="background-color:#0f0;col
 </pre>
 
 What we see here is that, overall, HTTP is faster. It's just slightly
-slower (1-5%) when sending extremely large string messages (ie
+slower (1-5%) when sending extremely large string messages (i.e.
 `type=bytes` rather than `type=buffer`). But otherwise, things are
 about the same, or slightly faster.
 
diff --git a/apps/site/pages/en/blog/vulnerability/october-2023-security-releases.md b/apps/site/pages/en/blog/vulnerability/october-2023-security-releases.md
index 0b62001e2f0f5..f62aa7ffb16f6 100644
--- a/apps/site/pages/en/blog/vulnerability/october-2023-security-releases.md
+++ b/apps/site/pages/en/blog/vulnerability/october-2023-security-releases.md
@@ -15,7 +15,7 @@ following issues.
 
 Undici did not always clear Cookie headers on cross-origin redirects. By design, cookie headers are [forbidden request headers](https://fetch.spec.whatwg.org/#forbidden-request-header), disallowing them to be set in RequestInit.headers in browser environments. Since undici handles headers more liberally than the spec, there was a disconnect from the assumptions the spec made, and undici's implementation of fetch.
 
-As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site.
+As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (i.e. an open redirector) to leak the cookie to the 3rd party site.
 
 More details area available in [GHSA-wqq4-5wpv-mx2g](https://github.com/nodejs/undici/security/advisories/GHSA-wqq4-5wpv-mx2g)
 
diff --git a/apps/site/pages/en/learn/getting-started/nodejs-with-webassembly.md b/apps/site/pages/en/learn/getting-started/nodejs-with-webassembly.md
index eb6dbcd55a2bd..ae80baa8f1e5c 100644
--- a/apps/site/pages/en/learn/getting-started/nodejs-with-webassembly.md
+++ b/apps/site/pages/en/learn/getting-started/nodejs-with-webassembly.md
@@ -12,7 +12,7 @@ The WebAssembly specification details two file formats, a binary format called a
 
 ## Key Concepts
 
-- Module - A compiled WebAssembly binary, ie a `.wasm` file.
+- Module - A compiled WebAssembly binary, i.e. a `.wasm` file.
 - Memory - A resizable ArrayBuffer.
 - Table - A resizable typed array of references not stored in Memory.
 - Instance - An instantiation of a Module with its Memory, Table, and variables.
diff --git a/apps/site/pages/en/learn/modules/publishing-a-package.mdx b/apps/site/pages/en/learn/modules/publishing-a-package.mdx
index aee351ebe14cc..58dcd1886355b 100644
--- a/apps/site/pages/en/learn/modules/publishing-a-package.mdx
+++ b/apps/site/pages/en/learn/modules/publishing-a-package.mdx
@@ -539,7 +539,7 @@ So when you see configuration options citing or named with `require` or `import`
 
 ⚠️ Adding an `"exports"` field/field-set to a package’s configuration effectively [blocks deep pathing into the package](https://nodejs.org/api/packages.html#package-entry-points) for anything not explicitly listed in the exports’ subpathing. This means it can be a breaking change.
 
-⚠️ Consider carefully whether to distribute both CJS and ESM: It creates the potential for the [Dual Package Hazard](#the-dual-package-hazard) (especially if misconfigured and the consumer tries to get clever). This can lead to an extremely confusing bug in consuming projects, especially when your package is not perfectly configured. Consumers can even be blind-sided by an intermediary package that uses the "other" format of your package (eg consumer uses the ESM distribution, and some other package the consumer is also using itself uses the CJS distribution). If your package is in any way stateful, consuming both the CJS and ESM distributions will result in parallel states (which is almost surely unintentional).
+⚠️ Consider carefully whether to distribute both CJS and ESM: It creates the potential for the [Dual Package Hazard](#the-dual-package-hazard) (especially if misconfigured and the consumer tries to get clever). This can lead to an extremely confusing bug in consuming projects, especially when your package is not perfectly configured. Consumers can even be blind-sided by an intermediary package that uses the "other" format of your package (e.g. consumer uses the ESM distribution, and some other package the consumer is also using itself uses the CJS distribution). If your package is in any way stateful, consuming both the CJS and ESM distributions will result in parallel states (which is almost surely unintentional).
 
 ### The dual-package hazard
 
diff --git a/apps/site/pages/en/learn/typescript/publishing-a-ts-package.md b/apps/site/pages/en/learn/typescript/publishing-a-ts-package.md
index 1a289ac1619f7..6d895feb721cd 100644
--- a/apps/site/pages/en/learn/typescript/publishing-a-ts-package.md
+++ b/apps/site/pages/en/learn/typescript/publishing-a-ts-package.md
@@ -136,7 +136,7 @@ const bar: number = 1 + foo;
 
 TypeScript has warned that the above code will not behave as intended, just like a unit test warns that code does not behave as intended. They are complementary and verify different things—you should have both.
 
-Your editor (eg VS Code) likely has built-in support for TypeScript, displaying errors as you work. If not, and/or you missed those, CI will have your back.
+Your editor (e.g. VS Code) likely has built-in support for TypeScript, displaying errors as you work. If not, and/or you missed those, CI will have your back.
 
 The following [GitHub Action](https://github.com/features/actions) sets up a CI task to automatically check (and require) types pass inspection for a PR into the `main` branch.
 
diff --git a/apps/site/scripts/release-post/index.mjs b/apps/site/scripts/release-post/index.mjs
index f41f60e49321c..b7aba6e8ebfec 100644
--- a/apps/site/scripts/release-post/index.mjs
+++ b/apps/site/scripts/release-post/index.mjs
@@ -174,7 +174,7 @@ const verifyDownloads = version =>
   Promise.all(downloadsTable(version).map(urlOrComingSoon));
 
 const findAuthorLogin = (version, section) => {
-  // looking for the @author part of the release header, eg:
+  // looking for the @author part of the release header, e.g.:
   // ## 2016-03-08, Version 5.8.0 (Stable). @Fishrock123
   // ## 2015-10-13, Version 4.2.1 'Argon' (LTS), @jasnell
   // ## 2015-09-08, Version 4.0.0 (Stable), @rvagg