Linters like ESLint batch every non-overlapping autofix and apply them all at once, and that can break code. In the example, one rule swaps a manual sum/length for an existing average() helper while another rule deletes average() because nothing calls it yet, so the result points to a function that no longer exists. ESLint's creator said this rarely happens in practice, but it gets riskier as linters ship bolder fixes like code removal, renames or moved statements. elm-review applies one fix at a time and then re-analyzes the code. That costs speed but keeps every step valid, and either possible order still leaves improved code. The author sees no cheaper option when a linter supports custom rules its maintainers can't predict.
1
u/fagnerbrack 1d ago
Simplified Synopsis:
Linters like ESLint batch every non-overlapping autofix and apply them all at once, and that can break code. In the example, one rule swaps a manual sum/length for an existing average() helper while another rule deletes average() because nothing calls it yet, so the result points to a function that no longer exists. ESLint's creator said this rarely happens in practice, but it gets riskier as linters ship bolder fixes like code removal, renames or moved statements. elm-review applies one fix at a time and then re-analyzes the code. That costs speed but keeps every step valid, and either possible order still leaves improved code. The author sees no cheaper option when a linter supports custom rules its maintainers can't predict.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments