I don't have a problem with the idea of a formatter (gofmt is freaking amazing), but Prettier itself makes extremely asinine and frustrating formatting decisions.
> It may not always be beautiful, but at least it's consistent and readable.
"Consistent" as in a consistent set of rules applied across the team, sure. But Prettier-formatted code ends up being extremely internally inconsistent. The best example (and the one that drives me bonkers the most) is function parameters (both traditional params and destructured-object params). Prettier forces you to go with whatever decision IT thinks is best about lining stuff up, meaning it'll force you to change:
And THEN it'll reformat it to a vertical list. Which is what I wanted all along! I could go on about other formatting BS it does (hooks in React are another good example) but I think I got my point across.
Again, like- I don't necessarily think formatters are a bad thing in principle. What I hate is the fact that the most commonly used formatter in JS-land is so mediocre in its output.
Your specific example makes perfect sense to me. It starts wrapping when you exceed the line length limit. It would be a bad formatter if it didn't do that.
One of the main selling points of Prettier for a lot of people is that it is extremely opinionated and leaves very little formatting choices up to the user. If you respect user-introduced whitespace then the same code written by two different people can end up formatted differently, which is precisely the problem Prettier is trying to to solve.
I would argue the example posted above is still "consistent" because the rules Prettier follows for line breaks (and everything else) are consistent throughout the codebase. Things will be on one line until the line is too long or complex, and then it will break to multiple lines. The rules don't change depending on who was writing the code, what the code is, or any other factors. It may not be formatted exactly how you want, but that's kind of the whole point. It's formatted how Prettier wants, and that's the only option.
> It may not always be beautiful, but at least it's consistent and readable.
"Consistent" as in a consistent set of rules applied across the team, sure. But Prettier-formatted code ends up being extremely internally inconsistent. The best example (and the one that drives me bonkers the most) is function parameters (both traditional params and destructured-object params). Prettier forces you to go with whatever decision IT thinks is best about lining stuff up, meaning it'll force you to change:
into That is, until you add another param: And THEN it'll reformat it to a vertical list. Which is what I wanted all along! I could go on about other formatting BS it does (hooks in React are another good example) but I think I got my point across.Again, like- I don't necessarily think formatters are a bad thing in principle. What I hate is the fact that the most commonly used formatter in JS-land is so mediocre in its output.