DEV Community

Discussion on: Adding Prettier to a Project

piotrlewandowski profile image
Piotr Lewandowski • Edited on

Oh dear, that escalated quickly.... Small hint for you guys: if you cannot discuss things in internet in polite manner take some offline hobby instead, I don't know, grow carrots, or something? :) And come back here only when you grow up? :)

Thread Thread
psiho profile image
Mirko Vukušić

@piotrlewandowski , I did that very, very long time ago. Might say the same, but it would be personal insult and is not my style. I admit to be passionate in discussions, as any average Mediterranean is, but not personal. Closest to that I came was saying "you don't read" after being acused for the same. On the other hand, I was treated with stuff like "solo dev", not wanting to write consistent code, being to shallow to get sarcasm,... and now to be a kid that needs to grow up.

Enough said in this thread. For the sake of the few reading this long thread,... Why/when not Prettier? If you have small enough team and are willing to setup your own formatting standards you can agree on them and implement them with tools like Eslint or your langserver: autofix formatting, do it on save, require it on commit, etc. You may spend more time configuring but decissions about formatting standards will not be taken away from your team and almost the same consistency can be achieved. In example, if you want to allow matrix style layout for props/params sometimes, or 'hide' some repeating long lines of code to avoid scrolling down to more important stuff, etc... you might find that Prettier code is not allways prettier nor more efficient to manage. The bigger your team is, or more diversified, ... opinionated formatters will be more usable. You'll win some and loose some but in general win will be bigger.
But again, for small(er) teams, at least run some of your projects through Prettier and see if it causes more frustration than it cuts down formatting inconsistencies, compared to non-opinionated tools like Eslint.