Not to mention it dirties up version control. It's a lot easier to tell which _significant_ things changed from the last commit when you're scanning a diff and no formatting changes are highlighted.
I also think formatting should be separate from linting but because they both require a parser people seem to think theyre the same thing.
If youre adding more attributes to a jsx component later and know it you might format to multiline early. It decides to undo your work and slow you down, because some arbitrary line length.
Similarly, if you go over that line length, on something you want single line for readability of structure, it just straight up does what it wants.
Im 100% on the auto format train but it has to go the gofmt route and only apply rules that are actually important and incredibly uncontroversial.
What you're missing here is that you're supposed to be using it all along, all the time. Format on save. Format on commit. Format on server pipelines. Format all the time. It can never 'undo' anything if it's what's providing the formatting in the first place.
https://prettier.io/docs/en/rationale.html#multi-line-object...
My two cents: Write the comment's purpose inside it. "// Comment inserted to force prettier line break until more attributes are added"
If the rule never works for you, turn that one off.
If the rule is what you want 99% of the time but it made this one line look dumb, mark that one block #ignore and let the team decide in CR if that was the right call.
Anyway, my point still stands, drop rules about line length and rules that care about inter line break positions and most of these problems go away.
If your contributor is changing thousands of lines in a diff to fix a typo, ask them not to do that :)
Now the code is formatted and additions won’t trigger reformatting the line or the file.
Of course, a lot of tooling simply isn't there for that, unfortunately, but that's what I see as the ideal solution.