docs: fix typos and bugs in design docs and meeting notes

GOVERNANCE.md

@@ -33,7 +33,7 @@ There is no specific set of requirements or qualifications for Team Membership b
 
 Changes to Team membership should be proposed with an issue and labelled `loaders-agenda`
 to be included in the next [team meeting](#team-meetings). Decisions are made via the
-[Consensus Seeking Process](#consensus-seeking-process). If there are not objections in the
+[Consensus Seeking Process](#consensus-seeking-process). If there are no objections in the
 issue new members may attend the meeting in which their membership is officially accepted.
 
 If a Team member is unable to attend a meeting where a planned membership decision is being made,
@@ -114,7 +114,7 @@ user experience for ECMAScript, CommonJS, and other loaders supported by Node.js
 
 Pull requests not included under the _special exemptions_ section below must
 reach consensus in a meeting in order to be merged into this repository. A pull
-request that is is unable to reach consensus cannot be merged into this
+request that is unable to reach consensus cannot be merged into this
 repository.
 
 ### Special Exemptions to the PR landing process

README.md

@@ -40,7 +40,7 @@ This team is spun off from the [Modules team](https://github.com/nodejs/modules)
 
    - [ ] Start with helpers for retrieving the closest parent `package.json` associated with a specifier string; and for retrieving the `package.json` for a particular package by name (which is not necessarily the same result).
 
-   - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that psuedocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.)
+   - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that pseudocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.)
 
    - [ ] Follow up with similar helper functions that make up what happens within Node’s internal `load`. (Definitions to come.)
 

doc/design/proposal-ambient-loaders.md

@@ -48,7 +48,7 @@ Let’s imagine we have the following loaders:
 - yaml, which adds yaml file support to `import`
 - coffeescript, which adds coffeescript file support to `import`
 
-The first two are critical to a successful resolution: without `zip`, PnP wouldn't be able to load files from the zip archives. Without `pnp`, Node would look for the `yaml` and `coffeescript` loaders into a `node_modules` folder, which would fail. On the other hand, `yaml` and `coffeescript` don't depend on each other.
+The first two are critical to a successful resolution: without `zip`, PnP wouldn't be able to load files from the zip archives. Without `pnp`, Node would look for the `yaml` and `coffeescript` loaders in a `node_modules` folder, which would fail. On the other hand, `yaml` and `coffeescript` don't depend on each other.
 
 The command line would end up like this (in practice `--ambient-loader` would probably be passed via `NODE_OPTIONS` rather than directly on the command line):
 

doc/design/proposal-chaining-iterative.md

@@ -4,7 +4,7 @@
 
 Say you had a chain of three loaders:
 
-1. `unpkg` resolves a specifier `foo` to an URL `http://unpkg.com/foo`.
+1. `unpkg` resolves a specifier `foo` to a URL `http://unpkg.com/foo`.
 2. `http-to-https` rewrites that URL to `https://unpkg.com/foo`.
 3. `cache-buster` takes the URL and adds a timestamp to the end, like `https://unpkg.com/foo?ts=1234567890`.
 
@@ -76,7 +76,7 @@ export async function resolve(
 ) {
   const url = new URL(interimResult.url); // this can throw, so handle appropriately
 
-  if (url.protocol = 'http:') url.protocol = 'https:';
+  if (url.protocol === 'http:') url.protocol = 'https:';
 
   return { url: url.toString() };
 }
@@ -210,7 +210,7 @@ const mimeTypeToFormat = new Map([
 export async function load(
   interimResult, // possibly output of https-loader
   context,
-  defaulLoad,
+  defaultLoad,
 ) {
   const { resolvedUrl } = context;
   if (!coffeescriptExtensionsRgx.test(resolvedUrl)) return; // step aside
@@ -220,7 +220,7 @@ export async function load(
 
   const rawSource = (
     interimResult.source
-    || await defaulLoad(resolvedUrl, { ...context, format }).source
+    || await defaultLoad(resolvedUrl, { ...context, format }).source
   )
   const transformedSource = CoffeeScript.compile(rawSource.toString(), {
     bare: true,
@@ -247,7 +247,7 @@ const coffeescriptExtensionsRgs = /* … */
 export async function load(
   interimResult, // possibly output of coffeescript-loader
   context,
-  defaulLoad,
+  defaultLoad,
 ) {
   const { resolvedUrl } = context;
   const babelConfig = await getBabelConfig(resolvedUrl);
@@ -261,7 +261,7 @@ export async function load(
 
   const sourceToTranspile = (
     interimResult.source
-    || await defaulLoad(resolvedUrl, { ...context, format }).source
+    || await defaultLoad(resolvedUrl, { ...context, format }).source
   );
   const transformedSource = Babel.transformSync(
     sourceToTranspile.toString(),

doc/design/proposal-chaining-middleware.md

@@ -4,7 +4,7 @@
 
 Say you had a chain of three loaders:
 
-1. `unpkg` resolves a specifier `foo` to an URL `http://unpkg.com/foo`.
+1. `unpkg` resolves a specifier `foo` to a URL `http://unpkg.com/foo`.
 2. `http-to-https` rewrites that URL to `https://unpkg.com/foo`.
 3. `cache-buster` takes the URL and adds a timestamp to the end, like `https://unpkg.com/foo?ts=1234567890`.
 
@@ -59,7 +59,7 @@ export async function resolve(
 
   const url = new URL(result.url);
 
-  if (url.protocol !== 'data:')) { // `data:` URLs don’t support query strings
+  if (url.protocol !== 'data:') { // `data:` URLs don’t support query strings
     url.searchParams.set('ts', Date.now());
   }
 

doc/design/proposal-strip-types.md

@@ -3,7 +3,7 @@
 ## Problem
 
 TypeScript support has been for a few years at the top of the list of features that users want to see in Node.js.
-Discussion has been on going for a few years [#43818](https://github.com/nodejs/node/issues/43818), and the main blocker has been the lack of a clear on long term support.
+Discussion has been ongoing for a few years [#43818](https://github.com/nodejs/node/issues/43818), and the main blocker has been the lack of a clear long-term support.
 TypeScript does not follow semver, and the Node.js project has been reluctant to commit to supporting TypeScript in the long term, given that the lifespan of an LTS version is 3 years.
 
 ## Goals
@@ -58,7 +58,7 @@ This is an issue that should apply to all tools that execute TypeScript at runti
 ### No type checking
 
 Type checking should be done by user land tools during development, and not at runtime.
-By performing at runtime, we would be adding large overhead.
+By performing it at runtime, we would be adding large overhead.
 
 ### Running TypeScript in node_modules
 

doc/meetings/2024-06-18.md

@@ -51,7 +51,7 @@
   * Jakob: how would it be for preImport to be async and resolve and load be sync. What happens if preImport is not done
   * Guy: preImport blocks. Not doing any module graph linking until the promise of preImport finishes. Works with dynamic import because dynamic import is async. It wouldn’t work for require(esm) either. The same constraints apply for CJS that it can not require(network).
   * Geoffrey: it doesn’t work with TLA, the same restriction. Can not work with require(TLA)
-  * Geoffrey: based on Joyee’s design doc, make a new doc describe resole and load migrate to on-thread, synchronizing, describe what happens to register, and land it and implement it on main before october.
+  * Geoffrey: based on Joyee’s design doc, make a new doc describe resolve and load migrate to on-thread, synchronizing, describe what happens to register, and land it and implement it on main before october.
   * Geoffrey: preImport hook as a follow-up.
   * Jakob: design doc is the way to go.
   * Joyee: might be too much on my doc?
@@ -66,7 +66,7 @@
   * Geoffrey: not on a main thread, doesn’t mean you are on a loader thread
   * Guy: the current register model is really great, you 
   * Guy: Joyee’s model is not obvious how a worker is attached. Automatically get registered loaders work for worker threads would be great
-  * Joyee: whether sharing source code or instances. I think people are strongly against having shared instances across threads. Nice to have a shared configuration, rather than shread instance. Someone from sentry: is there a way to configure loader, instead of loading a package.
+  * Joyee: whether sharing source code or instances. I think people are strongly against having shared instances across threads. Nice to have a shared configuration, rather than shared instance. Someone from sentry: is there a way to configure loader, instead of loading a package.
   * Joyee: API seems for instance. configuration for source codes.
   * Guy: beneficial to have a worker inherit configured loaders
   * Joyee: most intuitive behavior people in issues, suppose you don’t want to share?

doc/meetings/2024-07-02.md

@@ -42,7 +42,7 @@
   * Joyee: At least for Node.js the ship has shipped that you can do anything, like spawning a process. Browsers are supposed to run untrusted code. Node.js runs trusted code, that is the security model. 
   * Geoffrey: @joyee what’s your opinion on inheriting main thread’s loader settings?
   * Joyee: in the thread, people want it to be able to configure at library level and user level.
-  * Geoffrey: a user case is that TypeScript loaders. As an author of TypeScript library, a user register TypeScript loader at the entry, within the library, it can decide if it wants register in the worker or child process. What would the downside be the confiurability here.
+  * Geoffrey: a use case is that TypeScript loaders. As an author of TypeScript library, a user register TypeScript loader at the entry, within the library, it can decide if it wants register in the worker or child process. What would the downside be the configurability here.
   * Guy: I think loader authors won’t think about worker that much. On the API side, needs clarification on how the registration works.
 
 ### Open Discussion

doc/roadmap-2024.md

@@ -44,7 +44,7 @@ Before extending into new frontiers, we need to improve the loaders API enough t
 
    - [ ] Start with helpers for retrieving the closest parent `package.json` associated with a specifier string; and for retrieving the `package.json` for a particular package by name (which is not necessarily the same result).
 
-   - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that psuedocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.)
+   - [ ] Potentially include all the functions that make up the ESM resolution algorithm as defined in the [spec](https://nodejs.org/api/esm.html#resolution-algorithm-specification). Create helper functions for each of the functions defined in that pseudocode: `esmResolve`, `packageImportsResolve`, `packageResolve`, `esmFileFormat`, `packageSelfResolve`, `readPackageJson`, `packageExportsResolve`, `lookupPackageScope`, `packageTargetResolve`, `packageImportsExportsResolve`, `patternKeyCompare`. (Not necessarily all with these exact names, but corresponding to these functions from the spec.)
 
    - [ ] Follow up with similar helper functions that make up what happens within Node’s internal `load`. (Definitions to come.)