Throwing shade at Prettier
I don't use Prettier. I started writing code in the 90s when there were no formatters, and formatting for readability is something I do without thinking about it. My colleagues do use it. They see formatting as a burden. Perhaps their preference could be attributed to never having worked with the rudimentary IDEs that I initially did.
Their reason for using Prettier is a perfectly valid one: they would rather delegate the chore of code formatting to an electronic butler. But the rise to fame of Prettier can be attributed to reasons which are not as valid.
Prettier "[stops] all the on-going debates over styles"
That quote is directly from the official website. There are two types of "debates" over styles: ones where alignment is crucial, and others where it is largely irrelevant.
Tabs or spaces? Is there special casing for constants? For major things (and there are maybe two or three I haven't mentioned here) reaching a consensus is important. Upon joining a project, I swiftly look at existing code to understand the style, and I adhere to it. When I start fresh, the team expresses their preferences and then settles on something. Does settling take longer than 5 minutes? Run! This team will nitpick over trivialities until the end of time. Run while you still can!
The other type of debate covers questions such as: should we keep this on one line or break it into two? And my answer is: do whatever feels right. I would never block a pull request because I think a line break is (un)necessary. If you encounter reviewers who do this, see it as an opportunity to remind them that productive code reviewing focuses on substance, not aesthetics.
Prettier is perfectly consistent
Is that important?
Not to me. I don't lose sleep over human bias in code formatting. If you do, recognise it for what it is: a mini obsession.
We can pretend that having slight formatting inconsistencies is a problem. It isn't. It does not reduce the quality of your code. It confuses not a single reader of your code. It introduces no bugs.
Prettier makes Git diffs shorter
This argument doesn't hold water. Au contraire: when one renames a variable or function, Prettier might decide to spread single lines of code across multiple lines as they are now deemed too long (or vice versa). This produces lengthier Git diffs than any human would.
Is Prettier bad?
Prettier is often embraced as yet another futile attempt to assure quality through imposing rules and restrictions. And that doesn't work. There are a thousand and one ways a developer can make a mess of things. The rules you introduce will never cover even half of them. Policing everyone is a losing game. Over-regulation is counterproductive. In the end, you need to place trust in your team. And if you can't ‒ if loosening the leashes would create mayhem ‒ there's a deep problem in your team culture that needs addressing.
My choice to manually format code will persist. I don't find it a burden, and the result often closely resembles code formatted by Prettier. For those considering Prettier, go ahead, but do it for the right reason: because you have something of a fetish for hyper-consistency (I won't judge!), and/or you dislike thinking about formatting.