Prettier - The Beauty and The Beast
What is my point of view?
My opinion on prettier is heavily influenced by the scenarios I work with it. One is in open source projects; the other one is at work. We work in a mono repository environment, meaning that the code to be formatted is in a subdirectory of the repository. We are also a team of ten developers with approximately 10 different editors.
The beautiful side
Your code will be more concise than ever, and no one will argue about bracket spacing, trailing commas, indentation and stuff like that. You will free your brain from thinking about these kinds of things. You will we able to refuse every related linting rule, so no more red box errors as you pump in a console.log for debugging.
As you don’t need to keep style conventions in mind your development flow will become a lot more fluid; you can spend your time thinking about the content rather than the formatting of your code. That may read pretty trivial, but I experienced an increased development speed from the first minute.
Another thing I like about prettier is that your codebase is concise by default, especially if you install it in a pre-commit hook. Working with many different people in one code base may lead to different code styles. Yes, you can use eslint, but having to do nothing manually is a great benefit. Especially if the code style changes over time, running one command is easier than changing the linting rule and go through your entire code base.
The beasty side
Speaking of working with different people means also working with a lot of editors. Ensuring everyone on the team has the same version of prettier in their editor plugin (as some plugins don’t use the already installed version) and has the same configuration (as there is no workspace config, yet) is a problem growing with the size of the team. Quite a lot of frustration can come up, for example, when changing a file leads to unrelated diffs.
The way we currently solve this is by running prettier from time to time and tell people who introduced the changes that their config is broken. We consider better ways:
For starters prettier will soon come up with a workspace configuration option that may solve this issue quite well. This addresses the misconfiguration issue, but we also have people in our team who don’t want to use prettier in their development. Using a pre-commit hook would be the normal solution, but having a mono repository this is not that easy to be done.
CI to the rescue
In order to prevent these inconsistencies to enter your code base having a failing test in the CI in place. Our current setups looks similar to this and works great so far.
Prettier will most likely speed up your development workflow and will leverage consistency in your code base. In a project with many people involved it may also lead to people not using it and causing problems for the others. Installing a check in your CI helps with issues like this.