Have custom formatters be supplied custom data supplied by the rule and/or command line

The version of ESLint you are using.

5.16.0

The problem you want to solve.

Create a custom formatter to extract out all of my to-do text reported by no-warning-comments (since issues #875 and #4409 have been, imo regrettably, rejected), and this was the approach recommended in #875.

While I very much would prefer having the option to get this information in the context of my other linting issues, I would at least like some way to get at my to-do text in an ES-aware manner.

Your take on the correct solution to problem.

If you will not support reporting the message, I would at least like custom formatters to provide access, through the results object to the specific node (so I could use node.value to get at the triggering comment itself, rather than going through the pointless work of having to parse the whole file, something I could do without eslint).

Are you willing to submit a pull request to implement this change?

Not at this time.

I’d also like to suggest adding–if there is no way possible–for a rule to report custom data back depending on what it discovered in code, so that, e.g., a no warning comment based formatter (or rule) could ascertain a priority level out of the comment, e.g., // Todo (2): ... might indicate a level priority two to-do. (I don’t think this can be added to meta, as that appears static, and I’d like the priority reported to depend on the specific to-do message.) Perhaps if node is added back, rules could be allowed to add a custom property to the node to indicate their own meta-data such as this.

Thanks!

[nzakas]

Thanks for the suggestion. Unfortunately, this isn’t practical for us to implement. The initial version of ESLint actually did keep complete nodes with error messages but it caused ESLint to crash when linting large numbers of files due to running out of memory.

That said, there are two much easier solutions to your problem:

1. Create a custom rule that does exactly what you want.
2. Use the error location information to retrieve the comment from the source text directly. Each result provides the text of file and you can pull what you need from that. See https://eslint.org/docs/developer-guide/working-with-custom-formatters#the-result-object

Of the two, I think a custom rule is really the best solution for what you are working for.

[brettz9]

I see, thanks.

However, there is another use case which is different but related for passing along command line arguments, though in this case to fixers instead of formatters–where one can have optional fixer rules.

In eslint-plugin-jsdoc, we have a number of cases where not all users would want to apply all possible fixers by default. Though we can add regular rule options or settings which serve to determine which specific fixers should be applied, besides this being a somewhat uncomfortable mixing of conerns, it is a little more cumbersome to work around the lack of fixer CLI options.

I.e., we’d have to re-specify the rule along with the fixer-options, e.g., eslint --fix --rule 'myRule: [2, {removeExtraParamNames: true}]') instead of something more clean and not limited to a single rule, e.g., eslint --fix --fixer-removeExtraParamNames.