From b97aeba27c18c1213eb057c147d6240e3119bf46 Mon Sep 17 00:00:00 2001 From: Michael Schmidt Date: Tue, 18 Jul 2023 12:25:18 +0200 Subject: [PATCH] Fixed a few typos in docs (#542) * Fixed a few typos in docs * Updated tests --- README.md | 2 +- docs/rules/confusing-quantifier.md | 2 +- docs/rules/hexadecimal-escape.md | 2 +- docs/rules/index.md | 2 +- docs/rules/no-empty-lookarounds-assertion.md | 2 +- docs/rules/no-misleading-capturing-group.md | 2 +- docs/rules/no-optional-assertion.md | 2 +- docs/rules/no-super-linear-backtracking.md | 2 +- docs/rules/no-super-linear-move.md | 6 +-- docs/rules/no-unused-capturing-group.md | 2 +- docs/rules/no-useless-backreference.md | 6 +-- docs/rules/no-useless-lazy.md | 2 +- docs/rules/no-useless-quantifier.md | 2 +- docs/rules/no-useless-range.md | 4 +- docs/rules/optimal-lookaround-quantifier.md | 7 ++-- .../rules/optimal-quantifier-concatenation.md | 4 +- .../prefer-escape-replacement-dollar-char.md | 2 +- docs/rules/require-unicode-regexp.md | 2 +- docs/rules/sort-alternatives.md | 2 +- lib/rules/no-useless-range.ts | 5 +-- tests/lib/rules/no-useless-range.ts | 40 +++++++++---------- 21 files changed, 49 insertions(+), 51 deletions(-) diff --git a/README.md b/README.md index 6cc0fd2e9..34b8295c6 100644 --- a/README.md +++ b/README.md @@ -154,7 +154,7 @@ The `plugin:regexp/all` config enables all rules. It's meant for testing, not fo | [no-useless-flag](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-flag.html) | disallow unnecessary regex flags | | ✅ | 🔧 | | | [no-useless-lazy](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-lazy.html) | disallow unnecessarily non-greedy quantifiers | ✅ | | 🔧 | | | [no-useless-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-quantifier.html) | disallow quantifiers that can be removed | ✅ | | 🔧 | 💡 | -| [no-useless-range](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-range.html) | disallow unnecessary range of characters by using a hyphen | ✅ | | 🔧 | | +| [no-useless-range](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-range.html) | disallow unnecessary character ranges | ✅ | | 🔧 | | | [no-useless-two-nums-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-useless-two-nums-quantifier.html) | disallow unnecessary `{n,m}` quantifier | ✅ | | 🔧 | | | [no-zero-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-zero-quantifier.html) | disallow quantifiers with a maximum of zero | ✅ | | | 💡 | | [optimal-lookaround-quantifier](https://ota-meshi.github.io/eslint-plugin-regexp/rules/optimal-lookaround-quantifier.html) | disallow the alternatives of lookarounds that end with a non-constant quantifier | | ✅ | | | diff --git a/docs/rules/confusing-quantifier.md b/docs/rules/confusing-quantifier.md index 204c8ffbb..95872ee10 100644 --- a/docs/rules/confusing-quantifier.md +++ b/docs/rules/confusing-quantifier.md @@ -18,7 +18,7 @@ since: "v0.8.0" Confusing quantifiers are ones which imply one thing but don't deliver on that. An example of this is `(?:a?b*|c+){4}`. The group is quantified with `{4}` which -implies that at least 4 characters will be matched but this is not the case. The +implies that at least 4 characters will be matched, but this is not the case. The whole pattern will match the empty string. It does that because in the `a?b*` alternative, it's possible to choose 0 many `a` and `b`. So rather than `{4}`, `{0,4}` should be used to reflect the fact that the empty string can be matched. diff --git a/docs/rules/hexadecimal-escape.md b/docs/rules/hexadecimal-escape.md index a1bdc0209..5dfe2a432 100644 --- a/docs/rules/hexadecimal-escape.md +++ b/docs/rules/hexadecimal-escape.md @@ -17,7 +17,7 @@ since: "v0.9.0" Characters that can use hexadecimal escape can use both hexadecimal escape and unicode escape. -This rule aims is enforces the consistent use of hexadecimal escapes. +This rule aims to enforce the consistent use of hexadecimal escapes. diff --git a/docs/rules/index.md b/docs/rules/index.md index 8e7ca6eda..445ebae4c 100644 --- a/docs/rules/index.md +++ b/docs/rules/index.md @@ -61,7 +61,7 @@ sidebarDepth: 0 | [no-useless-flag](no-useless-flag.md) | disallow unnecessary regex flags | | ✅ | 🔧 | | | [no-useless-lazy](no-useless-lazy.md) | disallow unnecessarily non-greedy quantifiers | ✅ | | 🔧 | | | [no-useless-quantifier](no-useless-quantifier.md) | disallow quantifiers that can be removed | ✅ | | 🔧 | 💡 | -| [no-useless-range](no-useless-range.md) | disallow unnecessary range of characters by using a hyphen | ✅ | | 🔧 | | +| [no-useless-range](no-useless-range.md) | disallow unnecessary character ranges | ✅ | | 🔧 | | | [no-useless-two-nums-quantifier](no-useless-two-nums-quantifier.md) | disallow unnecessary `{n,m}` quantifier | ✅ | | 🔧 | | | [no-zero-quantifier](no-zero-quantifier.md) | disallow quantifiers with a maximum of zero | ✅ | | | 💡 | | [optimal-lookaround-quantifier](optimal-lookaround-quantifier.md) | disallow the alternatives of lookarounds that end with a non-constant quantifier | | ✅ | | | diff --git a/docs/rules/no-empty-lookarounds-assertion.md b/docs/rules/no-empty-lookarounds-assertion.md index 66953cd84..29044e017 100644 --- a/docs/rules/no-empty-lookarounds-assertion.md +++ b/docs/rules/no-empty-lookarounds-assertion.md @@ -23,7 +23,7 @@ An empty lookaround is a lookaround for which at least one path in the lookaroun **Examples:** -- `(?=)`: One of simplest empty lookarounds. +- `(?=)`: One of the simplest empty lookarounds. - `(?=a*)`: It is possible for `a*` to not consume characters, therefore the lookahead is _empty_. - `(?=a|b*)`: Only one path has to not consume characters. Since it is possible for `b*` to not consume characters, the lookahead is _empty_. - `(?=a|$)`: This is **not** an empty lookaround. `$` does not _consume_ characters but it does _assert_ characters. Similarly, all other standard assertions (`\b`, `\B`, `^`) are also not empty. diff --git a/docs/rules/no-misleading-capturing-group.md b/docs/rules/no-misleading-capturing-group.md index 1fd463a34..08d2ec2da 100644 --- a/docs/rules/no-misleading-capturing-group.md +++ b/docs/rules/no-misleading-capturing-group.md @@ -58,7 +58,7 @@ var foo = /^(a*).+/ This rule will report quantifiers at the end of capturing groups that might backtrack for certain strings. - E.g. when `/^(a*).+$/m` is used to match the string `"aa"`, then `a*` will capture both `a`s at first, but is then force to give up the last `a` to `.+` to make the whole regex accept. So `(a*)` only capture the first `a`. This is misleading because one would expect that `(a*)` should capture all `a`s at the start of the string, but this is not the case. + E.g. when `/^(a*).+$/m` is used to match the string `"aa"`, then `a*` will capture both `a`s at first, but is then forced to give up the last `a` to `.+` to make the whole regex accept. So `(a*)` only capture the first `a`. This is misleading because one would expect that `(a*)` should capture all `a`s at the start of the string, but this is not the case. Because this behavior might be intentional, some users might want to turn off this type of reporting. diff --git a/docs/rules/no-optional-assertion.md b/docs/rules/no-optional-assertion.md index b22a23273..b633049dc 100644 --- a/docs/rules/no-optional-assertion.md +++ b/docs/rules/no-optional-assertion.md @@ -17,7 +17,7 @@ since: "v0.9.0" Assertions that are quantified (directly or indirectly) can be considered optional if the quantifier has a minimum of zero. -A simple example is the following pattern: `/a(?:$)*b/`. The `$` assertion will reject but if that happens, it will simply be ignored because of the `*` quantifier. The assertion is optional, serving no function whatsoever. +A simple example is the following pattern: `/a(?:$)*b/`. The `$` assertion will reject, but if that happens it will simply be ignored because of the `*` quantifier. The assertion is optional, serving no function whatsoever. More generally, an assertion is optional, if there exists a parent quantifier with a minimum of zero such that all possible paths of the quantified element that contain the assertion do not consume characters. diff --git a/docs/rules/no-super-linear-backtracking.md b/docs/rules/no-super-linear-backtracking.md index 14732e44a..8286cf569 100644 --- a/docs/rules/no-super-linear-backtracking.md +++ b/docs/rules/no-super-linear-backtracking.md @@ -67,7 +67,7 @@ Every input string that exploits super-linear worst-case runtime can be separate For some regexes it is not possible to find a rejecting suffix even though the regex contains exploitable ambiguity (e.g. `/(?:a+)+/`). These regexes are safe as long as they are used as is. However, regexes can also be used as building blocks to create more complex regexes. In this case, the ambiguity might cause super-linear backtracking in the composite regex. -This options control whether ambiguity that might cause super-linear backtracking will be reported. +These options control whether ambiguity that might cause super-linear backtracking will be reported. - `report: "certain"` (_default_) diff --git a/docs/rules/no-super-linear-move.md b/docs/rules/no-super-linear-move.md index be1bed71e..b620c6970 100644 --- a/docs/rules/no-super-linear-move.md +++ b/docs/rules/no-super-linear-move.md @@ -39,7 +39,7 @@ var foo = /<.*?>/; Regexes are often used to find text of within a string (e.g. `/abc/.exec("123 abc def")`). The position of the matching text is unknown and has to be determined by the regex engine. In practice, the regex engine will move the regex across the input string character by character. While there are many optimizations to skip parts of the input string, there will still be _O(n)_ possible positions. If there is no text matching the regex in the input string, then all _O(n)_ positions will be checked. -This is not problem in it self, _O(n)_ is expected for linear string searching algorithms. +This is not a problem in itself, _O(n)_ is expected for linear string searching algorithms. Problems arise when the regex itself takes more than _O(1)_ steps (on average) to reject any position within the input. @@ -65,7 +65,7 @@ This rule says that the first `\s*` causes quadratic runtime for "any attack str The problem with `\s*` is that `\s` also allows line break characters (the characters in the attack string). `^` already ensures the "start of a line" requirement, so there is no reason to allow line breaks after the `^`. -The fix is to remove all line break characters from `\s`. This is difficult, so let's cheat a little and say that only spaces and tabs (`[\t ]`) are allows to surround the key. +The fix is to remove all line break characters from `\s`. This is difficult, so let's cheat a little and say that only spaces and tabs (`[\t ]`) are allowed to surround the key. @@ -83,7 +83,7 @@ var fix = /^[\t ]*(\w+)[\t ]*[:=]/m #### Limit the quantifier -All quantifiers reported by this rule are unbound (= maximum is infinite). This is because attackers need strings with a lengths >1000 character to exploit the quadratic runtime. +All quantifiers reported by this rule are unbound (= maximum is infinite). This is because attackers need strings with lengths >1000 character to exploit the quadratic runtime. If the quantifier simply stops searching after some maximum number of steps, the quantifier isn't exploitable. diff --git a/docs/rules/no-unused-capturing-group.md b/docs/rules/no-unused-capturing-group.md index d81883a7a..3b5cae219 100644 --- a/docs/rules/no-unused-capturing-group.md +++ b/docs/rules/no-unused-capturing-group.md @@ -69,7 +69,7 @@ This is by design. Capturing groups (as the name suggests) captured their matche A capturing group is intended to store its matched text so it can later be used, e.g. in text replacements. -That makes a capturing group quite similar to a variable in that its value (the captured text) is stored (by the regex engine) and can be accessed afterward (by the developer). However, if the captured text is not used, then the capturing group will essentially be an unused variable. This makes the regex harder to understand because other developers will have to constantly ask themselves: "Is this a capturing group because the captured text will be used later on in the code, or because `()` is faster to type?" +That makes a capturing group quite similar to a variable, in that its value (the captured text) is stored (by the regex engine) and can be accessed afterward (by the developer). However, if the captured text is not used, then the capturing group will essentially be an unused variable. This makes the regex harder to understand because other developers will have to constantly ask themselves: "Is this a capturing group because the captured text will be used later on in the code, or because `()` is faster to type?" Using capturing groups only if the captured text is used makes their usage unambiguous and easier for others to understand. diff --git a/docs/rules/no-useless-backreference.md b/docs/rules/no-useless-backreference.md index 5d1bc847d..2852b645d 100644 --- a/docs/rules/no-useless-backreference.md +++ b/docs/rules/no-useless-backreference.md @@ -25,7 +25,7 @@ Backreferences can be useless for multiple reasons. #### Empty capturing groups -The is the easiest reason. The references capturing group does not consume any characters (e.g. `/(\b)a\1/`). Since the capturing group can only capture the empty string, the backreference is guaranteed to accept any input. +The simplest reason. The references capturing group does not consume any characters (e.g. `/(\b)a\1/`). Since the capturing group can only capture the empty string, the backreference is guaranteed to accept any input. #### Nested backreferences @@ -39,7 +39,7 @@ If a backreference and its referenced capturing group are in different alternati #### Forward references and backward references -Backreferences are supposed to be matched **after** their referenced capturing group. Since regular expressions are matched from left to right, backreferences usually appear to the right of to their referenced capturing groups (e.g. `/(a)\1/`). However, backreferences can also be placed before (to the left of) their referenced capturing group (e.g. `/\1(a)/`). These backreferences are to trivially accept because the captured text of their referenced groups is undefined. We call these backreferences _forward references_. +Backreferences are supposed to be matched **after** their referenced capturing group. Since regular expressions are matched from left to right, backreferences usually appear to the right of their referenced capturing groups (e.g. `/(a)\1/`). However, backreferences can also be placed before (to the left of) their referenced capturing group (e.g. `/\1(a)/`). These backreferences are to trivially accept because the captured text of their referenced groups is undefined. We call these backreferences _forward references_. Inside **lookbehind assertions**, regular expressions are matched from right to left and not from left to right. This means that only backreferences now have to appear to the left of their respective capturing group to be matched after them (e.g. `/(?<=\1(a))/`). Backreferences placed to before (to the right of) their referenced capturing group inside lookbehinds are guaranteed to trivially accept. We call these backreferences _backward references_. @@ -50,7 +50,7 @@ If the referenced capturing group of a backreference is inside a negated lookaro To understand why this is the case, let's look at the example `/(?!(a))\w\1/y`. 1. Let's assume the input string is `ab`.
- Since `(a)` accepts the character `a`, `(?!(a))` will reject. So the input is reject before the backreference `\1` can be reached. + Since `(a)` accepts the character `a`, `(?!(a))` will reject. So the input is rejected before the backreference `\1` can be reached. The result of `/(?!(a))\w\1/y.exec("ab")` is `null`. 2. Let's assume the input string is `bc`.
diff --git a/docs/rules/no-useless-lazy.md b/docs/rules/no-useless-lazy.md index c04f070dd..c49920b53 100644 --- a/docs/rules/no-useless-lazy.md +++ b/docs/rules/no-useless-lazy.md @@ -29,7 +29,7 @@ There are two reasons why a lazy quantifier doesn't have to lazy: In the example above, the character `a` and the character `b` do not overlap. Therefore the quantifier `a+` is possessive. - Since an effectively possessive quantifier cannot give up characters to the expression after it, it doesn't matter whether the quantifier greedy or lazy. However, greedy quantifiers should be preferred because they require less characters to write and are easier to visually parse. + Since an effectively possessive quantifier cannot give up characters to the expression after it, it doesn't matter whether the quantifier greedy or lazy. However, greedy quantifiers should be preferred because they require fewer characters to write and are easier to visually parse. diff --git a/docs/rules/no-useless-quantifier.md b/docs/rules/no-useless-quantifier.md index 3d4046ca9..0c641dd61 100644 --- a/docs/rules/no-useless-quantifier.md +++ b/docs/rules/no-useless-quantifier.md @@ -19,7 +19,7 @@ since: "v0.10.0" This rule reports quantifiers that can trivially be removed without affecting the pattern. -This rule only fixes constant one quantifiers (e.g. `a{1}`). All other reported useless quantifiers hint at programmer oversight or fundamental problems with the pattern. +This rule only fixes constant-one quantifiers (e.g. `a{1}`). All other reported useless quantifiers hint at programmer oversight or fundamental problems with the pattern. Examples: diff --git a/docs/rules/no-useless-range.md b/docs/rules/no-useless-range.md index b89e9cc4f..0bb0a4b9b 100644 --- a/docs/rules/no-useless-range.md +++ b/docs/rules/no-useless-range.md @@ -2,7 +2,7 @@ pageClass: "rule-details" sidebarDepth: 0 title: "regexp/no-useless-range" -description: "disallow unnecessary range of characters by using a hyphen" +description: "disallow unnecessary character ranges" since: "v0.3.0" --- # regexp/no-useless-range @@ -17,7 +17,7 @@ since: "v0.3.0" ## :book: Rule Details -This rule reports unnecessary range of characters by using a hyphen. e.g. `[a-a]` +This rule reports unnecessary character ranges. E.g. `[a-a]` diff --git a/docs/rules/optimal-lookaround-quantifier.md b/docs/rules/optimal-lookaround-quantifier.md index 1659c9357..83eada8d2 100644 --- a/docs/rules/optimal-lookaround-quantifier.md +++ b/docs/rules/optimal-lookaround-quantifier.md @@ -17,21 +17,20 @@ since: "v0.8.0" Non-constant quantifiers are quantifiers that describe a range (e.g. `?`, `*`, `+`, `{0,1}`, `{5,9}`, `{3,}`). They have to match some number of times (the -minimum) after which further matches are optional until a certain maximum (may -be infinite) is reached. +minimum) after which further matches are optional until a certain maximum (potentially infinite) is reached. It's obvious that `/ba{2}/` and `/ba{2,6}/` will match differently because of the different quantifiers of `a` but that not the case if for lookarounds. Both `/b(?=a{2})/` and `/b(?=a{2,6})/` will match strings the same way. I.e. for the input string `"baaa"`, both will create the same match arrays. The two regular -expression are actually equivalent, meaning that `(?=a{2})` is equivalent to +expressions are actually equivalent, meaning that `(?=a{2})` is equivalent to `(?=a{2,6})`. More generally, if a non-constant quantifier is an **end** of the expression tree of a **lookahead**, that quantifier can be replaced with a constant quantifier that matched the element minimum-if-the-non-constant-quantifier many times. For **lookbehinds**, the non-constant quantifier has to be at the -**start** of the expression tree as lookbehinds are matched from right to left. +**start** of the expression tree, as lookbehinds are matched from right to left. diff --git a/docs/rules/optimal-quantifier-concatenation.md b/docs/rules/optimal-quantifier-concatenation.md index 05b3e1b0c..91e66001d 100644 --- a/docs/rules/optimal-quantifier-concatenation.md +++ b/docs/rules/optimal-quantifier-concatenation.md @@ -59,7 +59,7 @@ var foo = /\w+(?:(a)|b)*/; ### `capturingGroups` -The type of concatenation this rule reports might be intentional around capturing groups. This option allows you turn of false unfixable reports around capturing groups. +The type of concatenation this rule reports might be intentional around capturing groups. This option allows you to turn off false unfixable reports around capturing groups. - `capturingGroups: "report"` (_default_) @@ -69,7 +69,7 @@ The type of concatenation this rule reports might be intentional around capturin Concatenations around quantifiers will not be reported. - If this option is used, it is recommend to have the [regexp/no-super-linear-backtracking] rule enabled to protect against ReDoS. + If this option is used, it is recommended to have the [regexp/no-super-linear-backtracking] rule enabled to protect against ReDoS. ## :books: Further reading diff --git a/docs/rules/prefer-escape-replacement-dollar-char.md b/docs/rules/prefer-escape-replacement-dollar-char.md index 26e9dda70..a78a99343 100644 --- a/docs/rules/prefer-escape-replacement-dollar-char.md +++ b/docs/rules/prefer-escape-replacement-dollar-char.md @@ -13,7 +13,7 @@ since: "v0.6.0" ## :book: Rule Details -This rule aims to enforce escape when using the `$` character in replacement pattern of string replacement. +This rule aims to enforce correct dollar sign escapes (`$$`) when using `$` in replacement pattern of string replacements. diff --git a/docs/rules/require-unicode-regexp.md b/docs/rules/require-unicode-regexp.md index 1ec7958c5..34de1aaa7 100644 --- a/docs/rules/require-unicode-regexp.md +++ b/docs/rules/require-unicode-regexp.md @@ -17,7 +17,7 @@ since: "v1.2.0" This rule reports regular expressions without the `u` flag. -It will automatically add the `u` flag to regular expression where it is statically guaranteed to be safe to do so. In all other cases, the developer has to check that adding the `u` flag doesn't cause the regex to behave incorrectly. +It will automatically add the `u` flag to regular expressions where it is statically guaranteed to be safe to do so. In all other cases, the developer has to check that adding the `u` flag doesn't cause the regex to behave incorrectly. This rule is inspired by the [require-unicode-regexp] rule. The position of the report is improved over the core rule and arguments of `new RegExp()` are also checked. diff --git a/docs/rules/sort-alternatives.md b/docs/rules/sort-alternatives.md index 52a33dceb..a039e84ab 100644 --- a/docs/rules/sort-alternatives.md +++ b/docs/rules/sort-alternatives.md @@ -17,7 +17,7 @@ since: "v0.12.0" This rule will sort alternatives to improve readability and maintainability. -The primary target of this rule are lists of words and/or numbers. These lists are somewhat common and sorting them makes it easy for readers to check whether a particular word or number is included. +The primary target of this rule are lists of words and/or numbers. These lists are somewhat common, and sorting them makes it easy for readers to check whether a particular word or number is included. This rule will only sort alternatives if reordering the alternatives doesn't affect the pattern. diff --git a/lib/rules/no-useless-range.ts b/lib/rules/no-useless-range.ts index f28f1a29d..a013272d8 100644 --- a/lib/rules/no-useless-range.ts +++ b/lib/rules/no-useless-range.ts @@ -5,8 +5,7 @@ import { createRule, defineRegexpVisitor } from "../utils" export default createRule("no-useless-range", { meta: { docs: { - description: - "disallow unnecessary range of characters by using a hyphen", + description: "disallow unnecessary character ranges", category: "Best Practices", recommended: true, }, @@ -14,7 +13,7 @@ export default createRule("no-useless-range", { schema: [], messages: { unexpected: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", }, type: "suggestion", // "problem", }, diff --git a/tests/lib/rules/no-useless-range.ts b/tests/lib/rules/no-useless-range.ts index 15830be72..b687abdb6 100644 --- a/tests/lib/rules/no-useless-range.ts +++ b/tests/lib/rules/no-useless-range.ts @@ -17,7 +17,7 @@ tester.run("no-useless-range", rule as any, { errors: [ { message: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", line: 1, column: 3, }, @@ -29,7 +29,7 @@ tester.run("no-useless-range", rule as any, { errors: [ { message: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", line: 1, column: 3, }, @@ -41,13 +41,13 @@ tester.run("no-useless-range", rule as any, { errors: [ { message: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", line: 1, column: 3, }, { message: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", line: 1, column: 7, }, @@ -59,7 +59,7 @@ tester.run("no-useless-range", rule as any, { errors: [ { message: - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", line: 1, column: 3, }, @@ -73,7 +73,7 @@ tester.run("no-useless-range", rule as any, { const s = "[a\\\\-c]" new RegExp(s)`, errors: [ - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", ], }, { @@ -82,7 +82,7 @@ tester.run("no-useless-range", rule as any, { new RegExp(s)`, output: null, errors: [ - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", ], }, { @@ -105,13 +105,13 @@ tester.run("no-useless-range", rule as any, { /[A-\\u004-5]/; `, errors: [ - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", ], }, { @@ -132,12 +132,12 @@ tester.run("no-useless-range", rule as any, { /[\\u 0023]/; `, errors: [ - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", - "Unexpected unnecessary range of characters by using a hyphen.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", + "Unexpected unnecessary character ranges. The hyphen is unnecessary.", ], }, ],