You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR adds an option to allow escape sequences in regexp character classes to the no-misleading-character-class rule. The new option only has effect on nodes whose source location can be statically determined with our tools. These are the same nodes that report granular errors:
regular expression literals
string literals as first arguments of the RegExp constructor
template literals without expressions as first arguments of the RegExp constructor
Is there anything you'd like reviewers to focus on?
I would like to fine tune this rule to allow only escape sequence that are not confusing, and I'm not sure I've got the right balance. For example /[\👍]/ contains an escape sequence where the backslash just escapes the next character without changing its value. I think that those escape sequences should be still forbidden even when the new option is set. Other cases are less trivial.
In the current implementation, the new option will allow any escape sequences except those where the character being escaped is prepended by one or more backslashes. If one or more of the characters in a group are escaped, the group will be allowed.
/[\n̅]/ allowed, \n is a non-trivial escape sequence /[\e̅]/ not allowed, \e is e
These two look like the same kind of possible error this rule targets - the sequence appears as a single character - so perhaps both should not be allowed?
/[\n̅]/ allowed, \n is a non-trivial escape sequence /[\e̅]/ not allowed, \e is e
These two look like the same kind of possible error this rule targets - the sequence appears as a single character - so perhaps both should not be allowed?
Maybe we could require that both characters in n̅ are escaped? I'm not sure, because the problem here seems to lie in the unescaped combining character itself rather than the grouping of characters, and the rule does not flag those characters everywhere. This means that character classes like /[̳]/ or /[\n\u0305̳abc]/ will remain allowed despite looking confusing.
Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.
Perhaps we could allow only sequences that consist exclusively of ASCII characters. So /[\n\u0305]/ would be allowed, but /[\n̅]/ or /[\n\̅]/ would be not. What do you think @mdjermanovic?
Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.
I think we can require that combining mark characters in a character class are only allowed when written as escape sequences; which is to say regardless of the previous character. This would be the most immediate solution to always disallow /[\n̅]/ and /[\u006e̅]/ along with /[\e̅]/. I'll work on an update.
Hi everyone, it looks like we lost track of this pull request. Please review and see what the next steps are. This pull request will auto-close in 7 days without an update.
acceptedThere is consensus among the team that this change meets the criteria for inclusionfeatureThis change adds a new feature to ESLintruleRelates to ESLint's core rules
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
mdjermanovic
added
the
accepted
Prerequisites checklist
What is the purpose of this pull request? (put an "X" next to an item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[X] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:
Fixes #15080
What changes did you make? (Give an overview)
This PR adds an option to allow escape sequences in regexp character classes to the
no-misleading-character-classrule. The new option only has effect on nodes whose source location can be statically determined with our tools. These are the same nodes that report granular errors:RegExpconstructorRegExpconstructorIs there anything you'd like reviewers to focus on?
I would like to fine tune this rule to allow only escape sequence that are not confusing, and I'm not sure I've got the right balance. For example
/[\👍]/contains an escape sequence where the backslash just escapes the next character without changing its value. I think that those escape sequences should be still forbidden even when the new option is set. Other cases are less trivial.In the current implementation, the new option will allow any escape sequences except those where the character being escaped is prepended by one or more backslashes. If one or more of the characters in a group are escaped, the group will be allowed.
/[A\u0301]//[👨\u200d👩\u200d👦]/u/[\n̅]/\nis a non-trivial escape sequence/[\e̅]/\eise