Prettier specifically annoys me to no end with this problem.

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.

> It decides to undo your work

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.

Thats what im talking about. If you add text to a line, and it goes over a length, it will reformat a jsx element into about 5 lines instead of 1. Similarly, when you add more than it needs because you want consistency, or know youll add more, and the formatter runs, often it undoes your work.

Prettier lets you control object literal formatting by inserting/removing the newline after the opening brace, I'm not sure why they don't do that for JSX elements.

https://prettier.io/docs/en/rationale.html#multi-line-object...

If you really want 5 lines, add a dummy // in there and will be forced to use 5 instead of 1. Dirty hack, but it works.

That, or a prettier-ignore comment above the JSX tag. I find your solution more elegant, though.

My two cents: Write the comment's purpose inside it. "// Comment inserted to force prettier line break until more attributes are added"

Im talking about adding an attribute in the next 5 minutes, no, im not going to add a comment, or an ignore line while im editing a component. Those are really awful work arounds to a man made problem.

It's tunable. Pick a line length you all agree on and when it reformats after that, that's what you asked for.

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.

Most autoformatters are under active development, and updates to them often causes changes in their behaviour. So you have to have all devs agree on the precise version of the formatter used, and even then you still need to do regular commits that contain nothing but a run of the newest version of the formatter on the codebase, which sadly destroys long term git blame.

Chromium has a presubmit that enforces that code is autoformatted. However, it only enforces this for changed lines, and in practice, it works pretty well.

this is a solved problem, pin your packages.

But you still have to update them every now and then otherwise you can't use new features of your language. Which gives you the issue of breakages again.

I dont think people want to hear that there are still problems with autoformatting text.

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.

Sure. Most large teams do this on a 6 month basis or when it is needed to implement something. Again, a solved problem.