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

`no-warning-comments` break on hyphen char #11471

Closed
pascalduez opened this Issue Mar 3, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@pascalduez
Copy link

pascalduez commented Mar 3, 2019

Tell us about your environment

  • ESLint Version: 5.15.0
  • Node Version: 11.10.1
  • npm Version: 6.8.0

What parser (default, Babel-ESLint, etc.) are you using?

babel-eslint

Please show your full configuration:

{
  "parser": "babel-eslint",
  "plugins": [
    "flowtype"
  ],
  "rules": {
    "flowtype/no-weak-types": 1,
    "no-warning-comments":  [2, { "terms": ["flow-typed signature", "flow-typed version"], "location": "start"}]
  }
}

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

Upgraded ESlint from 5.7.0 to 5.15.0.

eslint **/**/test_* --quiet

What did you expect to happen?

Linting 🦄

What actually happened? Please include the actual, raw output from ESLint.

The rule choke on the hypen in "flow-typed".

"no-warning-comments":  [2, { "terms": ["flow-typed signature", "flow-typed version"], "location": "start"}]
SyntaxError: Error while loading rule 'no-warning-comments': Invalid regular expression: /^\s*flow\-typed version\b/: Invalid escape
    at new RegExp (<anonymous>)
    at convertToRegExp (flow-typed/definitions/node_modules/eslint/lib/rules/no-warning-comments.js:98:24)
    at Array.map (<anonymous>)
    at Object.create (flow-typed/definitions/node_modules/eslint/lib/rules/no-warning-comments.js:109:45)
    at createRuleListeners (flow-typed/definitions/node_modules/eslint/lib/linter.js:578:21)
    at Object.keys.forEach.ruleId (flow-typed/definitions/node_modules/eslint/lib/linter.js:732:31)
    at Array.forEach (<anonymous>)
    at runRules (flow-typed/definitions/node_modules/eslint/lib/linter.js:690:34)
    at Linter._verifyWithoutProcessors (flow-typed/definitions/node_modules/eslint/lib/linter.js:894:31)
    at preprocess.map.textBlock (flow-typed/definitions/node_modules/eslint/lib/linter.js:943:35)

Are you willing to submit a pull request to fix this bug?

@not-an-aardvark

This comment has been minimized.

Copy link
Member

not-an-aardvark commented Mar 4, 2019

Hi, thanks for the report. I can reproduce this issue.

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

Fix: avoid creating invalid regexes in no-warning-comments (fixes #11471
)

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

Fix: avoid creating invalid regex in no-warning-comments (fixes #11471)
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.