Autofixes in processors
See original GitHub issueI’d like to reopen discussion about support for autofixing in processors. Now that autofixing is stabilized and we have more rules that can be fixed automatically, it feels like it would be helpful to support it for processors. This is continuation of the discussion from #5121
My proposal is to create an additional function called autoFix
in the processor definition. It will take two arguments, an array of strings with fixed text and filename. It’s job would be to combine passed in fixed text and original file text and return complete text of the modified file. ESLint will, at that point, write that file to disk.
I’ll open WIP PR with the changes. My only concern is using autofix in processors through API. Since API just gets back a list of messages, and not fixed text, location of those messages will be off. I’m not sure what would be a good approach to fix this issue, we can either strip autofix information from the messages, or require yet another function from the processor to fix location information for messages (or maybe require that postprocess
fix not only message locations, but also autofix locations as well?).
Issue Analytics
- State:
- Created 7 years ago
- Reactions:3
- Comments:32 (21 by maintainers)
The main reason that I’m concerned with @ilyavolodin’s proposal is that it forces the responsibility for accurately applying the fixes onto each plugin owner, whereas the logic for each of those is likely to be very similar.
I have a slightly different straw man proposal:
Are there any known plugins where the line given to eslint doesn’t map directly to a line in a source file, plus some configurable offset? It seems like this is by far the most common case. For example, consider this HTML file:
The HTML plugin will just give the following to eslint:
If you’re familiar with Javascript source maps that are used to help, for example, Chrome devtools debug compiled code, the concept is very similar. If no
source_map
is passed to eslint, then eslint can just say that--fix
isn’t supported for that plugin. In fact, if we find that the source map itself gets too big (what happened with real Javascript source maps), we could provide a library like the one that @platinumazure suggested that generates the compact source maps mentioned in the article above for plugin developers.This was accepted in today’s TSC meeting.