Lack of information about violated rule provided to postprocess function for a custom plugin processor

[ppatotski]

ESLint version: Latest version

Implementation:
Custom eslint plugin processor that traverses reported error messages (postprocess function). Problem: Lack of information about violated rule

Actual: Each message includes information about violated rule

Expect: Violated rule message includes a 'target' property in cases where it makes sense

Example: 'no-undef' rule has the following message:

{ ruleId: 'no-undef',
  severity: 2,
  message: '\'undefinedFunction\' is not defined.',
  line: 1,
  column: 1,
  nodeType: 'Identifier',
  source: 'undefinedFunction();' }

Expect:

{ ruleId: 'no-undef',
  severity: 2,
  message: '\'undefinedFunction\' is not defined.',
  target: 'undefinedFunction'
  line: 1,
  column: 1,
  nodeType: 'Identifier',
  source: 'undefinedFunction();' }

Current workaround is to regex message text in order to extract name of undefined function. However, it is not a reliable way since message format is not a strongly defined api.

[not-an-aardvark]

Could you elaborate on why you need to extract the name of the undefined function?

Also, #6740 and #9165 seem related.

[ppatotski]

I have a whitelist of 'undefined' function/var names and I would like to filter out errors based on it. The whitelist is very dynamic, so I cannot leverage globals or eslint-disable-line. Let me look into related items.

[platinumazure]

@ppatotski Is this still an issue?

[ilyavolodin]

This doesn't seem unique to processors. Our errors in general do not report things like that, because there are so many cases where it's not clear what is the target element that caused this error. We do report AST nodes in some of the rules, but they are normalized to line/column combination, since we assume that consumers might not have access to AST.

[ppatotski]

Looking at OOB rules I see a lot of rules report errors in the following way (example):

                context.report({
                    node,
                    message: "Unexpected '{{matchedTerm}}' comment.",
                    data: {
                        matchedTerm
                    }
                });

I wonder if there is a way to enable access to data for processors.

[not-an-aardvark]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn't get consensus from the team, so I'm closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design -- we can't realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they're worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn't need to be a blocker for you using this in your project, if you'd find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.

[ppatotski]

Well...Thanks for your time anyway.

[ppatotski]

I submitted PR (#9871) for consideration just in case you change your mind.