Various tweaks

Author: sindresorhus

docs/rules/no-array-for-each.md

@@ -14,7 +14,7 @@ Benefits of [`for…of` statement](https://developer.mozilla.org/en-US/docs/Web/
 - Ability to exit early with `break` or `return`
 - Ability to skip iterations with `continue`
 
-Additionally, using `for…of` has great benefits if you are using TypeScript, because it does not cause a function boundary to be crossed. This means that type-narrowing earlier on in the current scope will work properly while inside of the loop (without having to re-type-narrow). Furthermore, any mutated variables inside of the loop will picked up on for the purposes of determining if a variable is being used.
+Additionally, using `for…of` has great benefits if you are using TypeScript, because it does not cause a function boundary to be crossed. This means that type-narrowing earlier on in the current scope will work properly while inside of the loop (without having to re-type-narrow). Furthermore, any mutated variables inside of the loop will be picked up on for the purposes of determining if a variable is being used.
 
 ## Examples
 

docs/rules/no-array-method-this-argument.md

@@ -10,7 +10,7 @@
 The rule disallows using the `thisArg` argument in array methods:
 
 - If the callback is an arrow function or a bound function, the `thisArg` won't affect it.
-- If you intent to use a custom `this` in the callback, it's better to use the variable directly or use `callback.bind(thisArg)`.
+- If you intend to use a custom `this` in the callback, it's better to use the variable directly or use `callback.bind(thisArg)`.
 
 This rule checks following array methods accepts `thisArg`:
 

docs/rules/no-immediate-mutation.md

@@ -12,7 +12,7 @@ When you create a variable and immediately mutate it, you should instead include
 - Assign variable to an array literal and immediately mutate with `Array#{push,unshift}(…)`.
 - Assign variable to an object literal and immediately assign another property.
 - Assign variable to an object literal and immediately mutate with `Object.assign(…)`.
-- Assign variable to a `Set` or `WeakSet` from an array literal and immediately adding an new element with `{Set,WeakSet}.add(…)`.
+- Assign variable to a `Set` or `WeakSet` from an array literal and immediately adding a new element with `{Set,WeakSet}.add(…)`.
 - Assign variable to a `Map` or `WeakMap` from an array literal and immediately set another key with `{Map,WeakMap}.set(…, …)`.
 
 ## Examples

docs/rules/numeric-separators-style.md

@@ -82,7 +82,7 @@ Example:
 /* eslint unicorn/numeric-separators-style: ["error", {"onlyIfContainsSeparator": true, "binary": {"onlyIfContainsSeparator": false}] */
 const number = 100000; // Pass, this number does not contain separators
 const binary = 0b101010001; // Fail, `binary` type don't require separators
-const hexadecimal = 0xD_EED_BEE_F; // Fail, it contain separators and it's incorrectly grouped
+const hexadecimal = 0xD_EED_BEE_F; // Fail, it contains separators and it's incorrectly grouped
 ```
 
 **`minimumDigits`**

docs/rules/prefer-add-event-listener.md

@@ -11,7 +11,7 @@ Enforces the use of `.addEventListener()` and `.removeEventListener()` over thei
 
 In most cases, it is safe to replace the `on`-function with the corresponding `addEventListener` counterpart, which is why this rule contains a fixer that swaps it automatically for you. For example, you might be assigning some static functionality to a UI button when the page first loads, and in this context, the functionality of the two would be equivalent.
 
-However, __if you are assigning a listener in a dynamic context, then this rule's auto-fixer will make your code bugged__. This is because the `on` assignment replaces the current listener, but the `addEventListener` adds an additional listener in addition to the ones that are already assigned. For example, if you are dynamically updating the functionality of a button as new data comes in, then using `addEventListener` would not work, since it would cause N functions to be invoked for every previous data state. In this context, you should probably disable this lint rule and use the `on` form, since [removing existing event listeners is not possible](https://stackoverflow.com/questions/9251837/how-to-remove-all-listeners-in-an-element).
+However, __if you are assigning a listener in a dynamic context, then this rule's auto-fixer will make your code bugged__. This is because the `on` assignment replaces the current listener, but the `addEventListener` adds an additional listener to the ones that are already assigned. For example, if you are dynamically updating the functionality of a button as new data comes in, then using `addEventListener` would not work, since it would cause N functions to be invoked for every previous data state. In this context, you should probably disable this lint rule and use the `on` form, since [removing existing event listeners is not possible](https://stackoverflow.com/questions/9251837/how-to-remove-all-listeners-in-an-element).
 
 ## Examples
 

docs/rules/prefer-array-some.md

@@ -15,7 +15,7 @@ We only check `.filter().length > 0` and `.filter().length !== 0`. These two non
 
 - Using [`Array#find()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find) or [`Array#findLast()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLast) to ensure at least one element in the array passes a given check.
 
-- Comparing the result of [`Array#find()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find)  or [`Array#findLast()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLast) with `undefined`.
+- Comparing the result of [`Array#find()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/find) or [`Array#findLast()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLast) with `undefined`.
 
 - Using [`Array#findIndex()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findIndex) or [`Array#findLastIndex()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/findLastIndex) to ensure at least one element in the array passes a given check.
 

docs/rules/prefer-simple-condition-first.md

@@ -46,13 +46,13 @@ const x = bar || foo();
 
 ## Fix safety
 
-Expressions with side effects or throwing potential are not flagged, since reordering would change program behavior:
+Expressions with side effects or observable property reads are not flagged, since reordering would change program behavior:
 
 - Assignment expressions (`state.ready = true`)
 - Update expressions (`++counter`)
-- Deep member expression chains (`object.deep.value`)
+- Member expressions (`object.flag`, `object?.flag`, `object[index]`)
 - Tagged template expressions (`` tag`x` ``)
 
-When the complex side contains function calls or `new` expressions, the fix is provided as a **suggestion** rather than an auto-fix, because reordering changes when the call executes due to short-circuit evaluation.
+Expressions containing function calls or `new` expressions on the complex side are not flagged, because reordering them is not semantics-preserving under short-circuit evaluation.
 
-When both sides are side-effect-free (identifiers, simple member expressions, literals), the fix is applied automatically.
+When both sides are side-effect-free (identifiers, literals, and other pure expressions), the fix is applied automatically unless comments between the operands would be lost.

docs/rules/prefer-ternary.md

@@ -7,7 +7,7 @@
 <!-- end auto-generated rule header -->
 <!-- Do not manually modify this header. Run: `npm run fix:eslint-docs` -->
 
-This rule enforces the use of ternary expressions over  'simple' `if-else` statements, where 'simple' means the consequent and alternate are each one line and have the same basic type and form.
+This rule enforces the use of ternary expressions over 'simple' `if-else` statements, where 'simple' means the consequent and alternate are each one line and have the same basic type and form.
 
 Using an `if-else` statement typically results in more lines of code than a single-line ternary expression, which leads to an unnecessarily larger codebase that is more difficult to maintain.
 

docs/rules/prefer-type-error.md

@@ -11,7 +11,7 @@ This rule enforces you to throw a `TypeError` after a type checking if-statement
 
 It's aware of the most commonly used type checking operators and identifiers like `typeof`, `instanceof`, `.isString()`, etc, borrowed from [ES2017](https://tc39.github.io/ecma262/), [Underscore](https://underscorejs.org), [Lodash](https://lodash.com), and [jQuery](https://jquery.com). For a complete list of the recognized identifiers, please take a look at the [identifier-definition](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/rules/prefer-type-error.js#L3).
 
-The rule investigates every throw-statement which throws a generic `Error`. It will fail if the throw-statement is the only expression in the surrounding block and is preceeded by an if-statement whose condition consists of type-checks exclusively. You have to replace the `Error` with a `TypeError`.
+The rule investigates every throw-statement which throws a generic `Error`. It will fail if the throw-statement is the only expression in the surrounding block and is preceded by an if-statement whose condition consists of type-checks exclusively. You have to replace the `Error` with a `TypeError`.
 
 ## Examples
 

docs/rules/switch-case-break-position.md

@@ -10,6 +10,8 @@ Enforce that terminating statements (`break`, `return`, `continue`, `throw`) app
 
 This can happen when refactoring — for example, removing an `if` wrapper but leaving the `break` outside the braces.
 
+`break` and `continue` are auto-fixed. `return` and `throw` are still reported, but are left for manual fixes because moving them into the block can change lexical binding resolution.
+
 ## Examples
 
 ```js