docs: Mention character classes in no-useless-escape #15421
Conversation
|
|
eslint-github-bot
bot
added
triage
mdjermanovic
added
accepted
docs/rules/no-useless-escape.md
Outdated
| @@ -26,7 +26,8 @@ Examples of **incorrect** code for this rule: | |||
| `\#{foo}`; | |||
| /\!/; | |||
| /\@/; | |||
|
|
|||
| /[\[\]]/; | |||
There was a problem hiding this comment.
This example might be misleading because only one of the two escapes is useless, so it might be better to remove the other from the example?
| /[\[\]]/; | |
| /[\[]/; |
There was a problem hiding this comment.
Should the “correct” example also be adjusted? When the “incorrect” and “correct” examples are compared, it’s clear which escape is useless. I was kind of trying to include realistic examples and I’m not sure if /[\[]/ qualifies. Still, not sure what the best set of examples is.
There was a problem hiding this comment.
We can add to “correct” examples both /[[]/; to mirror the incorrect /[\[]/;, and /[[\]]/; to show that \] isn't useless.
There was a problem hiding this comment.
It looks a bit redundant this way. I think it looks good if in “incorrect”, there’s the example /[\[]/;, and in “correct”, there’s the two examples /[[]/; and /[\]]/.
(By the way, sorry for the delay. This week was busy…)
mdjermanovic
changed the title
eslint-github-bot
bot
added
the
archived due to age
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[X] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
What changes did you make? (Give an overview)
In regex literals,
/[\[]/and/[a\-]/contain useless escapes within character classes, but these cases are not very well-known, so I’ve included them. A recent Stack Overflow question (https://stackoverflow.com/q/70322972/4642212) prompted this PR, but of course there’s also issue #13826 right here: getting a linter warning for these cases may be confusing. Therefore, I’ve explicitly mentioned this in the documentation. Note: this behavior is already part of the tests.Is there anything you'd like reviewers to focus on?
Nothing specific.