Do linters really need to block merges over tiny formatting issues?

Blocking a merge is often intentional: the main branch should always pass its automated checks. However, a formatting-only lint failure should not necessarily require another human review. Many teams allow the original approval to remain valid when the only follow-up change was an automatic formatting fix. That workflow rule is separate from whether the linter itself should fail.

Yes, linters are common, but teams usually run them much earlier than the merge. Editors can lint while you work and automatically format things like indentation or blank lines when you save. Pre-commit hooks and CI checks then provide a second layer of protection, so formatting problems should rarely reach the review stage.

The exact behavior depends on the language and tool. Some linters are mainly editor warnings, while others are required checks in continuous integration. A missing newline may seem trivial, but consistent formatting prevents noisy diffs and arguments later. The frustrating part in your case was probably the review policy: the team should clarify whether automatic lint fixes need a fresh approval.

That is how I expected it to work. The linter itself was fine; having to repeat the review for one automatically fixable newline was the part that felt excessive.

Linters help keep a codebase consistent, especially when many developers have different preferences about spacing, braces, or line breaks. The easiest setup is to use a formatter configured with the same rules, run it on save, and include linting in the test or pre-commit process. Once that is established, linting becomes mostly invisible.