I have no opinions here.

cc @broady @campoy

Duplicate #21719?

Duplicate of #21719

While I twitch when I see inconsistent formatting in a bunch of the JS/CSS/etc., reformatting everything without any logic changes is churn that negates the usefulness of git blame.

For new files, I'm on board with using a standardized formatter so that we just don't need to worry about it (though honestly I wish we didn't have to install npm in order to get it).

That's what #21719 is about, but I'm not onboard with just fixing formatting for formatting's sake.

Unless I'm ignorant of some feature in git that allows you to avoid the scenario I describe above.

I see. I have completely forgot about git history. From that point of view it all makes sense. Thank you.

Preserving Git blame is not a good enough reason to avoid standardizing formatting. Git blame inevitably gets confused by uninteresting changes like adding ,. Breaking Git blame should be minimized but not outright avoided. When you're looking at Git blame, you always need to be prepared to dig deeper and go past the first superficial change to a line to find its real source deeper in history. A single formatting commit is easy enough to push past as long as one doesn't arbitrarily churn through formatting systems. Github now has a feature where you can hover next to a line to find prior changes, which makes it easy to daisy chain blame lookups to find the real source.