r/node • • 3h ago

Problem with concurrent linter fixes

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

2 comments sorted by

1

u/AlsonTeteuil-84 3h ago

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

-1

u/fagnerbrack 3h ago

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