Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpret user-provided regexes in rule options with the u flag #11423

Closed
not-an-aardvark opened this issue Feb 21, 2019 · 1 comment
Closed

Interpret user-provided regexes in rule options with the u flag #11423

not-an-aardvark opened this issue Feb 21, 2019 · 1 comment

Comments

@not-an-aardvark
Copy link
Member

@not-an-aardvark not-an-aardvark commented Feb 21, 2019

What rule do you want to change?

camelcase, capitalized-comments, default-case, dot-notation, handle-callback-err, id-match, line-comment-position, lines-around-comment, max-len, new-cap, no-fallthrough, no-unused-vars, spaced-comment and valid-jsdoc. (These are all of the rules that have options which are interpreted as regular expressions.)

Does this change cause the rule to produce more or fewer warnings?

In the vast majority of cases, the behavior would be the same. In cases where the source text contains astral symbols or other non-BMP characters, the rule may produce more or fewer warnings.

How will the change be implemented? (New option, new default behavior, etc.)?

This will be a new default behavior. I think this is the behavior that most users expect anyway, although they might not have noticed that the current behavior is different from their expectation.

This page contains a good summary of unicode regexes.

Please provide some example code that this change will affect:

/* eslint max-len: [
  error,
  25,
  {ignorePattern: "𝌆{2}"}
] */

var longNameLongNameLongName = '𝌆𝌆';

What does the rule currently do for this code?

The rule reports an error on the line with a variable declaration, even though it seems like that line should match the ignorePattern.

What will the rule do after it's changed?

The rule will no longer report an error, because it will interpret the ignore pattern as a unicode regex.

Are you willing to submit a pull request to implement this change?

Yes

@not-an-aardvark not-an-aardvark added this to Needs discussion in v6.0.0 Feb 21, 2019
@nzakas nzakas moved this from Needs discussion to Accepted, ready to implement in v6.0.0 Feb 28, 2019
@not-an-aardvark
Copy link
Member Author

@not-an-aardvark not-an-aardvark commented Mar 1, 2019

This issue was accepted in today's TSC meeting.

not-an-aardvark added a commit that referenced this issue Mar 4, 2019
)

5018378 changed the codebase to use unicode regexes almost everywhere, with the exception of places where regexes are constructed from user input. However, two issues occurred to cause a bug:

* Due to an oversight, the regular expressions constructed in the `no-warning-comments` rule were changed to be unicode regexes even though those regexes were constructed from user input.
* The `no-warning-comments` rule dynamically creates regexes with unnecessary escape characters, and unnecessary escape characters are invalid in unicode regexes.

This commit fixes the first issue. The second issue isn't a problem on its own, but it will need to be fixed in order to implement #11423.
not-an-aardvark added a commit that referenced this issue Mar 4, 2019
5018378 changed the codebase to use unicode regexes almost everywhere, with the exception of places where regexes are constructed from user input. However, two issues occurred to cause a bug:

* Due to an oversight, the regular expressions constructed in the `no-warning-comments` rule were changed to be unicode regexes even though those regexes were constructed from user input.
* The `no-warning-comments` rule dynamically creates regexes with unnecessary escape characters, and unnecessary escape characters are invalid in unicode regexes.

This commit fixes the first issue. The second issue isn't a problem on its own, but it will need to be fixed in order to implement #11423.
not-an-aardvark added a commit that referenced this issue Mar 5, 2019
… (#11472)

5018378 changed the codebase to use unicode regexes almost everywhere, with the exception of places where regexes are constructed from user input. However, two issues occurred to cause a bug:

* Due to an oversight, the regular expressions constructed in the `no-warning-comments` rule were changed to be unicode regexes even though those regexes were constructed from user input.
* The `no-warning-comments` rule dynamically creates regexes with unnecessary escape characters, and unnecessary escape characters are invalid in unicode regexes.

This commit fixes the first issue. The second issue isn't a problem on its own, but it will need to be fixed in order to implement #11423.
not-an-aardvark added a commit that referenced this issue Mar 16, 2019
This updates the core rules that interpret user-provided options as regular expressions. Those rules now interpret the options as unicode regexes, which avoids some cases of unexpected behavior with astral symbols.
@not-an-aardvark not-an-aardvark moved this from Accepted, ready to implement to Implemented, pending review in v6.0.0 Mar 16, 2019
@mysticatea mysticatea moved this from Implemented, pending review to Ready to merge in v6.0.0 Mar 28, 2019
v6.0.0 automation moved this from Ready to merge to Done Apr 1, 2019
not-an-aardvark added a commit that referenced this issue Apr 1, 2019
…11516)

This updates the core rules that interpret user-provided options as regular expressions. Those rules now interpret the options as unicode regexes, which avoids some cases of unexpected behavior with astral symbols.
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Sep 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
v6.0.0
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants