[Docs] extensions, order: fix a couple typos

Xunnamius · ljharb · commit 44827e7d48cf · 2024-11-25T22:45:15.000-08:00
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -6,6 +6,9 @@ This change log adheres to standards from [Keep a CHANGELOG](https://keepachange
 
 ## [Unreleased]
 
+### Changed
+- [Docs] `extensions`, `order`: fix a couple typos ([#3106], thanks [@Xunnamius])
+
 ## [2.31.0] - 2024-10-03
 
 ### Added
@@ -1152,6 +1155,7 @@ for info on changes for earlier releases.
 
 [`memo-parser`]: ./memo-parser/README.md
 
+[#3106]: https://github.com/import-js/eslint-plugin-import/pull/3106
 [#3073]: https://github.com/import-js/eslint-plugin-import/pull/3073
 [#3072]: https://github.com/import-js/eslint-plugin-import/pull/3072
 [#3071]: https://github.com/import-js/eslint-plugin-import/pull/3071
@@ -2018,6 +2022,7 @@ for info on changes for earlier releases.
 [@wtgtybhertgeghgtwtg]: https://github.com/wtgtybhertgeghgtwtg
 [@xM8WVqaG]: https://github.com/xM8WVqaG
 [@xpl]: https://github.com/xpl
+[@Xunnamius]: https://github.com/Xunnamius
 [@yesl-kim]: https://github.com/yesl-kim
 [@yndajas]: https://github.com/yndajas
 [@yordis]: https://github.com/yordis
diff --git a/docs/rules/extensions.md b/docs/rules/extensions.md
@@ -58,15 +58,11 @@ Default value of `ignorePackages` is `false`.
 
 By default, `import type` and `export type` style imports/exports are ignored. If you want to check them as well, you can set the `checkTypeImports` option to `true`.
 
-Unfortunately, in more advanced linting setups, such as when employing custom
-specifier aliases (e.g. you're using `eslint-import-resolver-alias`, `paths` in
-`tsconfig.json`, etc), this rule can be too coarse-grained when determining
-which imports to ignore and on which to enforce the law. This is especially
-troublesome if you have import specifiers that [look like externals or
-builtins](./order.md#how-imports-are-grouped).
+Unfortunately, in more advanced linting setups, such as when employing custom specifier aliases (e.g. you're using `eslint-import-resolver-alias`, `paths` in `tsconfig.json`, etc), this rule can be too coarse-grained when determining which imports to ignore and on which to enforce the config.
+This is especially troublesome if you have import specifiers that [look like externals or builtins](./order.md#how-imports-are-grouped).
 
-Set `pathGroupOverrides` to force this rule to always ignore certain imports and
-never ignore others. `pathGroupOverrides` accepts an array of one or more [`PathGroupOverride`](#pathgroupoverride) objects.
+Set `pathGroupOverrides` to force this rule to always ignore certain imports and never ignore others.
+`pathGroupOverrides` accepts an array of one or more [`PathGroupOverride`](#pathgroupoverride) objects.
 
 For example:
 
@@ -81,14 +77,12 @@ For example:
     },
     pathGroupOverrides: [
       {
-        {
-          pattern: "package-name-to-ignore",
-          action: "ignore",
-        },
-        {
-          pattern: "bespoke+alias:{*,*/**}",
-          action: "enforce",
-        }
+        pattern: "package-name-to-ignore",
+        action: "ignore",
+      },
+      {
+        pattern: "bespoke+alias:{*,*/**}",
+        action: "enforce",
       }
     ]
   }
@@ -97,17 +91,16 @@ For example:
 
 > \[!NOTE]
 >
-> `pathGroupOverrides` is inspired by [`pathGroups` in
-> `'import/order'`](./order.md#pathgroups) and shares a similar interface. If you're
-> using `pathGroups` already, you may find `pathGroupOverrides` very useful.
+> `pathGroupOverrides` is inspired by [`pathGroups` in `'import/order'`](./order.md#pathgroups) and shares a similar interface.
+> If you're using `pathGroups` already, you may find `pathGroupOverrides` very useful.
 
 #### `PathGroupOverride`
 
-|     property     | required |          type          | description                                                                                                                     |
-| :--------------: | :------: | :--------------------: | ------------------------------------------------------------------------------------------------------------------------------- |
-|     `pattern`    |    ☑️    |        `string`        | [Minimatch pattern][16] for specifier matching                                                                                  |
-| `patternOptions` |          |        `object`        | [Minimatch options][17]; default: `{nocomment: true}`                                                                           |
-|      `action`     |    ☑️    | `"enforce" \| "ignore"` | What action to take on imports whose specifiers match `pattern`                                      |
+|     property     | required |          type           | description                                                     |
+| :--------------: | :------: | :---------------------: | --------------------------------------------------------------- |
+|     `pattern`    |    ☑️     |        `string`         | [Minimatch pattern][16] for specifier matching                  |
+| `patternOptions` |          |        `object`         | [Minimatch options][17]; default: `{nocomment: true}`           |
+|      `action`    |    ☑️     | `"enforce" \| "ignore"` | What action to take on imports whose specifiers match `pattern` |
 
 ### Exception
 
diff --git a/docs/rules/order.md b/docs/rules/order.md
@@ -6,7 +6,7 @@
 
 Enforce a convention in the order of `require()` / `import` statements.
 
-With the [`groups`][2] option set to `["builtin", "external", "internal", "parent", "sibling", "index", "object", "type"]` the order is as shown in the following example:
+With the [`groups`][18] option set to `["builtin", "external", "internal", "parent", "sibling", "index", "object", "type"]` the order is as shown in the following example:
 
 ```ts
 // 1. node "builtin" modules
@@ -157,7 +157,7 @@ const identifier3 = require('specifier3');
 
 Roughly speaking, the grouping algorithm is as follows:
 
-1. If the import has no corresponding identifiers (e.g. `import'./my/thing.js'`), is otherwise "unassigned," or is an unsupported use of `require()`, and [`warnOnUnassignedImports`][5] is disabled, it will be ignored entirely since the order of these imports may be important for their [side-effects][31]
+1. If the import has no corresponding identifiers (e.g. `import './my/thing.js'`), is otherwise "unassigned," or is an unsupported use of `require()`, and [`warnOnUnassignedImports`][5] is disabled, it will be ignored entirely since the order of these imports may be important for their [side-effects][31]
 2. If the import is part of an arcane TypeScript declaration (e.g. `import log = console.log`), it will be considered **object**. However, note that external module references (e.g. `import x = require('z')`) are treated as normal `require()`s and import-exports (e.g. `export import w = y;`) are ignored entirely
 3. If the import is [type-only][6], `"type"` is in `groups`, and [`sortTypesAmongThemselves`][7] is disabled, it will be considered **type** (with additional implications if using [`pathGroups`][8] and `"type"` is in [`pathGroupsExcludedImportTypes`][9])
 4. If the import's specifier matches [`import/internal-regex`][28], it will be considered **internal**
@@ -298,7 +298,7 @@ Enforces or forbids new lines between import groups.
 
 - If set to `always`, at least one new line between each group will be enforced, and new lines inside a group will be forbidden
 
-  > \[!TIP]
+  > [!TIP]
   >
   > To prevent multiple lines between imports, the [`no-multiple-empty-lines` rule][21], or a tool like [Prettier][22], can be used.
 
@@ -552,11 +552,11 @@ Default: `false`
 
 > \[!NOTE]
 >
-> This setting is only meaningful when `"type"` is included in [`groups`][2].
+> This setting is only meaningful when `"type"` is included in [`groups`][18].
 
 Sort [type-only imports][6] separately from normal non-type imports.
 
-When enabled, the intragroup sort order of [type-only imports][6] will mirror the intergroup ordering of normal imports as defined by [`groups`][2], [`pathGroups`][8], etc.
+When enabled, the intragroup sort order of [type-only imports][6] will mirror the intergroup ordering of normal imports as defined by [`groups`][18], [`pathGroups`][8], etc.
 
 #### Example
 
@@ -612,13 +612,9 @@ Default: the value of [`newlines-between`][24]
 >
 > This setting is only meaningful when [`sortTypesAmongThemselves`][7] is enabled.
 
-Enforces or forbids new lines between _[type-only][6] import groups_, which only
-exist when [`sortTypesAmongThemselves`][7] is enabled. `newlines-between-types`
-is otherwise functionally identical to [`newlines-between`][24].
+`newlines-between-types` is functionally identical to [`newlines-between`][24] except it only enforces or forbids new lines between _[type-only][6] import groups_, which exist only when [`sortTypesAmongThemselves`][7] is enabled.
 
-In addition, when determining if a new line is enforceable or forbidden between
-the type-only imports and the normal imports, `newlines-between-types` takes
-precedence over [`newlines-between`][24].
+In addition, when determining if a new line is enforceable or forbidden between the type-only imports and the normal imports, `newlines-between-types` takes precedence over [`newlines-between`][24].
 
 #### Example
 
@@ -745,7 +741,7 @@ Default: `"never"`
 >
 > This setting is only meaningful when [`newlines-between`][24] and/or [`newlines-between-types`][27] is set to `"always-and-inside-groups"`.
 
-When set to `"inside-groups"`, this ensures imports spanning multiple lines are separated from other imports with a new line while single-line imports are grouped together (and the space between them consolidated) if they belong to the same [group][2] or [`pathGroups`][26].
+When set to `"inside-groups"`, this ensures imports spanning multiple lines are separated from other imports with a new line while single-line imports are grouped together (and the space between them consolidated) if they belong to the same [group][18] or [`pathGroups`][26].
 
 > \[!IMPORTANT]
 >
@@ -859,16 +855,11 @@ The same holds true for the next example; when given the following settings:
 
 > [!IMPORTANT]
 >
-> **Pay special attention to the value of
-> [`pathGroupsExcludedImportTypes`](#pathgroupsexcludedimporttypes)** in this
-> example's settings. Without it, the successful example below would fail. This is
-> because the imports with specifiers starting with "dirA/", "dirB/", and
-> "dirC/" are all [considered part of the `"external"`
-> group](#how-imports-are-grouped), and imports in that group are
-> excluded from [`pathGroups`](#pathgroups) matching by default.
+> **Pay special attention to the value of [`pathGroupsExcludedImportTypes`](#pathgroupsexcludedimporttypes)** in this example's settings.
+> Without it, the successful example below would fail.
+> This is because the imports with specifiers starting with "dirA/", "dirB/", and "dirC/" are all [considered part of the `"external"` group](#how-imports-are-grouped), and imports in that group are excluded from [`pathGroups`](#pathgroups) matching by default.
 >
-> The fix is to remove `"external"` (and, in this example, the others) from
-> [`pathGroupsExcludedImportTypes`](#pathgroupsexcludedimporttypes).
+> The fix is to remove `"external"` (and, in this example, the others) from [`pathGroupsExcludedImportTypes`](#pathgroupsexcludedimporttypes).
 
 This will fail the rule check:
 
@@ -1012,7 +1003,6 @@ import type { H } from './bbb';
 - [`import/core-modules`][11]
 
 [1]: https://eslint.org/docs/latest/user-guide/command-line-interface#--fix
-[2]: #groups-string
 [3]: #how-imports-are-grouped
 [4]: https://nodejs.org/api/esm.html#terminology
 [5]: #warnonunassignedimports
