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

Update: use regexpp's default ecmaVersion in no-control-regex #13969

Merged
merged 1 commit into from Jan 1, 2021

Conversation

mdjermanovic
Copy link
Member

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

Tell us about your environment

  • ESLint Version: v7.16.0
  • Node Version: v12.18.4
  • npm Version: v6.14.6

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

default

Please show your full configuration:

Configuration
module.exports = {
  parserOptions: {
    ecmaVersion: 2020
  }
};

What did you do? Please include the actual source code causing the issue.

Online Demo

/* eslint no-control-regex: error */

/(?<\u{1d49c}>.)\x1f/

What did you expect to happen?

1 error, since the regex is valid in ES2020 and there's an escape sequence for a control character.

When we flip the sequence and the group, the rule does report an error, as in this demo.

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

no errors

What changes did you make? (Give an overview)

Changed the no-control-regex rule to use regexpp's default ecmaVersion (currently 2020), instead of the hard-coded 2018.

It's similar to #13968, but for this rule the change means more errors as there are fewer parsing errors (this rule reports control characters until the first parsing failure).

Is there anything you'd like reviewers to focus on?

  • This rule doesn't pass the "u" flag, so it doesn't report \u{1f} and there are also false negatives like /\u{0}*\x1f/u. I'll open an issue for that.
  • It's interesting that both rules that use regexpp.RegExpValidator had hard-coded ecmaVersion 2018, but neither of rules that use regexpp.RegExpParser did.

@mdjermanovic mdjermanovic added bug ESLint is working incorrectly rule Relates to ESLint's core rules accepted There is consensus among the team that this change meets the criteria for inclusion labels Dec 30, 2020
@mdjermanovic mdjermanovic merged commit 535fe47 into master Jan 1, 2021
@mdjermanovic mdjermanovic deleted the nocontrolregex-ecmaversion branch January 1, 2021 18:11
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Jul 1, 2021
@eslint-github-bot eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Jul 1, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion bug ESLint is working incorrectly rule Relates to ESLint's core rules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants