This is such a waste of electricity IMO. Just occasionally batch-fix all files for syntax. Semantic linting can run in CI, as it's about catching bugs. But formatting is for long-term consistency and doesn't need to be done on every commit.

Occasionally batch-fixing syntax makes "git blame" far less useful.

Yup, but you need to reference the commit ID, meaning that you always need to create two commits, one for the reformatting, and a second one for updating the .git-blame-ignore-revs file. Additionally, you may not use git rebase, or any other workflow that modifies the history, or the references will be broken. Third, the git config needs to be set per-project (can't be set globally), so all developers need to manually adjust their config, for this feature to be useful.

If you value a clean commit history, then simply reformat as part of the code change. With autoformatting on save (e.g. through prettier), that's a complete non-issue anyways.

Until you change the formatting rules and the whole codebase is in one diff. This seems to happen at least once a year from my observations.

you may have to force approve edits by the formatter then, since they’re pretty annoying when included in changes for code review.

only in node.js, it's a waste of electricity.

in other language, formatters are pretty damn fast. never heard anyone complain about gofmt or cargo fmt

I'm not a lint fascist, but enforcing them gave our team: - less time reviewing: no more "you forgot to indent here" - less git conflicts: because of differences in trailing comas, line breaks, ... - less (to no more) code style debates: the linter is the benevolant dictator - less time making our code clean, thinking about line breaks: just get it done, the linter and CI will handle formatting !