Fix: use regexpp's default ecmaVersion in no-invalid-regexp

[mdjermanovic]

Prerequisites checklist

• I have read the contributing guidelines.

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-invalid-regexp: error */

/(?<\ud835\udc9c>.)/g;
new RegExp("(?<\\ud835\\udc9c>.)", "g");

/(?<\u{1d49c}>.)/g;
new RegExp("(?<\\u{1d49c}>.)", "g");

/(?<𝒜>.)/g;
new RegExp("(?<𝒜>.)", "g");

/\p{Script=Nandinagari}/u;
new RegExp("\\p{Script=Nandinagari}", "u");

What did you expect to happen?

No errors. These are valid regular expressions per the ES2020 spec, ref tc39/ecma262#1869 (comment) and tc39/ecma262#1468.

Espree with ecmaVersion: 2020 doesn't report parsing errors in the equivalent regex literals.

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

All four RegExp calls are reported:

   4:1  error  Invalid regular expression: /(?<\ud835\udc9c>.)/: Invalid capture group name  no-invalid-regexp
   7:1  error  Invalid regular expression: /(?<\u{1d49c}>.)/: Invalid capture group name     no-invalid-regexp
  10:1  error  Invalid regular expression: /(?<𝒜>.)/: Invalid capture group name            no-invalid-regexp
  13:1  error  Invalid regular expression: /\p{Script=Nandinagari}/u: Invalid property name  no-invalid-regexp

What changes did you make? (Give an overview)

In the no-invalid-regexp rule I removed the hard-coded ecmaVersion: 2018 passed into RegExpValidator so that the default regexpp's ecmaVersion is used, like in other rules that use regexpp. I think it's always the latest official version (not counting the draft?). In #10062 it was decided to use the latest version in this rule.

This currently bumps ecmaVersion from 2018 to 2020 in no-invalid-regexp.

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

• I believe this change can produce only fewer warnings.
• Should we use regexpp's default ecmaVersion, or set it to the max supported by regexpp if they will be different? The actual published regexpp doesn't support 2021, so it wouldn't make a difference at the moment.
• The previous valid tests are misleading because this rule doesn't use ecmaVersion from the configuration. Most of the allowConstructorFlags tests are thus useless. I'll submit a PR to modify the tests.
• "g" flag in the examples and the tests doesn't have a particular meaning, but I had to add some flags because the logic on when should the rule try to validate the regex both with and without the "u" flag is currently wrong. For example, new RegExp("\\u{0}*"); is a false negative (it's valid with the "u" flag, but that flag certainly isn't there in this case). I'll submit a PR to fix that.

[nzakas]

I think using the default is probably fine.