Supporting auto-fix in plugins with processors

Auto-fix for source code that was run through a processor was intentionally not implemented, presumably so we could get something working for auto-fix rather than trying to hit every corner case. I know there are still some issues with auto-fix that make it impractical to try to use it on many of our rules, but I believe this particular problem is quite solvable at this point.

Here is what I propose:

1. Processor objects may choose to include allowFixes: true in their properties, to indicate that the processor supports auto-fix.
2. If a processor supports auto-fix, it must either adjust fix ranges (to match actual location in the original file) or null out fix information for all messages in postprocess().
3. If a processor supports auto-fix, ESLint will assume that postprocess() has appropriately modified fix information (or removed it) and run SourceCodeFixer.applyFixes() (and otherwise process fixes as normal).

If a plugin processors does not indicate that it supports auto-fix, the current behavior would remain (i.e., ESLint would not process fixes at all).

Example of processor that supports auto-fix:

processors: {
    ".txt": {
        preprocess: function (text, filename) {
            return [text];
        },
        postprocess: function (messages, filename) {
            return messages[0];
        },
        allowFixes: true
    }
}

I’m certainly open to suggestions here- what I’ve proposed was the simplest and most natural approach I could think of.

<bountysource-plugin>

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource. </bountysource-plugin>

[nzakas]

I’d like to suggest we table this discussion for now. We have some larger open questions about how we will be doing autofix in the future, so I don’t think it makes sense to continue taking about this very specific use case outside of the larger context of auto-fixing improvements.

[nzakas]

Unfortunately, it looks like consensus couldn’t be reached on this issue and so I’m closing it. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach consensus after 21 days tend never to reach consensus, and as such, we close those issues. This doesn’t mean the idea isn’t interesting, just that it’s not something the team can commit to.