Allow more control over fixes in CLIEngine

I’ll talk a little about the use case I’m attempting to solve, and then my proposed solution:

Problem

Currently, it is not a simple matter to tell ESLint to apply fixes from only one rule, or to disable particular rules from fixes. Per-rule autofixing is being discussed in https://github.com/eslint/eslint/issues/8018, and @ljharb mentioned his use case of fixing one single rule at a time. In a subsequent chat discussion, I learned that Airbnb also uses inline config to change some rules to warn severity, and he would like to avoid applying fixes to those lines. Currently, there is no built-in way that I know of for ESLint to support this use case.

Potential Solution

I would like to write a CLI tool (possibly an enhancement to eslint-nibble which would allow users to autofix one single rule at a time, while still respecting the rest of the eslint configuration in their .eslintrc file. Furthermore, I would like to allow an option to not fix messages with a severity of 1.

Unfortunately, this is not currently possible. To apply fixes with CLIEngine, it’s necessary to configure it with fix: true. This adds an output field to the results, which CLIEngine.outputFixes() applies to the filesystem. However, the creation of the error messages and output occur together, when calling CLIEngine.executeOnFiles or CLIEngine.executeOnText.

Proposal

My proposal is to allow users to modify the messages within report.results (for example, to strip out any messages with severity: 1 or all except a particular rule), before fixes are applied.

I have experimented with adding an applyFixesToReport method to CLIEngine, which would accept a report object, do a little bit of work to get sourceFile objects using our existing utilities, and then call SourceCodeFixer.applyFixes(), returning a new report including an output string if fixes were applied from the messages in the originally supplied report.

The changes to ESLint are pretty minimal using this approach, and would allow much more flexibility in the fixes that ESLint performs. I’d be happy to submit a PR if this suggestion is approved.

[nzakas]

What if fix could be a function that returns true if a passed-in message should be fixed?

[IanVS]

@ilyavolodin unfortunately it’s not quite that easy. .eslintrc contains more than just rules, including parser configurations, and --no-eslintrc will wipe all of that out. Also, you wouldn’t be able to avoid fixing warnings.