prefer-named-capture-group is reporting incorrect locations

[mdjermanovic]

Tell us about your environment

• ESLint Version: 6.3.0
• Node Version: 10.16.0
• npm Version: 6.9.0

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

default

Please show your full configuration:

Configuration

module.exports = {
  parserOptions: {
    ecmaVersion: 2015,
  }
};

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

Demo link

/*eslint prefer-named-capture-group: "error"*/

RegExp("\\d\\s(a)");

RegExp("(" + "a" + ")");

eslint index.js

What did you expect to happen?

2 errors, but not with incorrect locations.

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

3:13  error  Capture group '(a)' should be converted to a named or non-capturing group  prefer-named-capture-group
5:9   error  Capture group '(a)' should be converted to a named or non-capturing group  prefer-named-capture-group

/*eslint prefer-named-capture-group: "error"*/

RegExp("\\d\\s(a)"); // highlighting '\s('

RegExp("(" + "a" + ")"); // highlighting '(" '

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

Yes.

Perhaps if arguments[0] is not a string literal which raw is same as internal presentation, then report the location of the whole arguments[0]?

[mdjermanovic]

Marking this as accepted because this small bug is obvious.

I'll fix this, just need help with what would be a better solution:

1. Report the exact location of the disallowed group when it's possible, otherwise the whole arguments[0] node.
2. Or, always report the full location of the arguments[0] node, just to be consistent.
3. Or, always report the whole NewExpression/CallExpression node, that's how other regexp rules already work.

[g-plane]

I prefer Solution 1.

[platinumazure]

As I noted in the PR, I think I might (only slightly, not strongly) prefer solution 2. If we didn't specify the capture group content in the message, I would be strongly in favor of solution 1, but as it is, I think solution 2 would be a good experience for most users.