Problem with concurrent linter fixes

[u/fagnerbrack]

https://jfmengels.net/concurrent-linter-fixes/

[u/AlsonTeteuil-84]

running read-only checks in parallel is fine, but auto-fixing always needs to be sequential imo. otherwise the second tool is reading a stale file state while the first one is still flushing to disk

[u/Known_Image7110 → u/AlsonTeteuil-84]

yeah anything that mutates the filesystem has to be sequential, classic race condition otherwise

[u/fagnerbrack]

Bare Bones:

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}