Problem with concurrent linter fixes

Linters, like ESLint for JavaScript, can sometimes simultaneously fix multiple issues during an analysis. This behavior can introduce problems that wouldn't have occurred if the fixes were applied individually after re-analyzing the code. For instance, in the example example.js file, applying two fixes - using 'average' in the definition of 'averageScore' and removing 'average' - would yield incorrect code.

The linter, upon running the analysis for both rules, applies both fixes concurrently and then re-runs the analysis to find an additional fix - in this case, removing 'sum' which can now be removed. While ESLint creator Nicholas C. Zakas noted that this is rare and not a significant problem, the possibility still exists. To address this issue, I implemented a solution where only one fix is applied at a time, followed by re-analysis of the code.

This approach ensures that only sensible fixes are applied at any given time, even if it means the linter spends more time analyzing the project. However, this solution may be slower than alternative methods, such as prioritization for collision detection. This problem can occur with any pair of rules that make significant code changes on their own.

The only way to avoid this issue is to control the rules, as custom rules are not always known to the tool maintainers.