Why aren’t you using Prettier?
Talking with someone about the huge number of options that exist in the JavaScript world, a question came up: If you have to pick just one tool released over the last few years, what would it be? For me, it’s Prettier.
A code formatter. It’s very easy to start using it (you can start by just installing a plugin to your editor) and the benefits are many and immediate. It’s hard to find a better return of investment.
In this post I’ll try to explain why.
A brief history
Prettier has been around for less than 6 months and it’s already being used by many big companies and projects. Its history can be summarized in 6 tweets:
What does it do
Prettier is a code formatter. It takes code as input and spits out the same code with a prettier format.
What sets Prettier apart from other JS formatters is how comprehensive it is. Because it drops all the original styling and formats the code from its syntax tree, the output style is always consistent. Consistent spaces, commas, semicolons, parens, braces, and consistent line breaks.
For example, these three functions have the same syntax tree:
For Prettier they look all the same, so it will format them consistently with the same style:
Or if we choose a smaller line length:
How it works
Prettier formats your code in three steps:
- First it parses the code to its abstract syntax tree (AST), getting ride of (almost) all the original formatting.
- Then it transform the AST into another tree using some opinionated rules to group code fragments in a hierarchy that defines where new lines can be inserted if necessary.
- Finally, it prints the intermediate tree to a string, choosing the best places to add line-breaks based on the max line length (the default is 80).
Let’s see, for example, how var x = foooo + baaar gets formatted.
First the input string is parsed to AST. The AST looks something like this:
The AST include details about “var”, “x”, “+”, “foooo” and “baaar”, but nothing about spaces, line-breaks, semicolons or any other stylistic stuff that doesn’t matter at runtime. This AST is used as input for the next step that generates a document tree like this one:
Here you can see again “var”, “x”, “foooo”, mixed with some spaces, semicolons and a few Prettier commands. The structure of this tree depends on the stylistic opinions of Prettier.
In this case, three Prettier commands are being used. line indicates that a line-break can be inserted if its needed, if not, a space will be inserted. indent increases the level of indentation (only if the content is printed on a new line). group marks items which the printer should try to fit on one line, if it doesn’t fit it will break the outermost group and try again. There are more commands, for example hardline identifies a line that will always be included in the output.
Note that we have two line on the document, this means that there are only two places where line-breaks can be inserted. So, if the full document doesn’t fit on one line, it first will break after =. If it still doesn’t fit, it will break after +:
How to use it
The easiest way to use Prettier would be to install it on your editor of choice and use a shortcut to trigger the formatting of the active file.
It’s recommended to also install Prettier as a local npm dependency so everyone that works on the project uses the same version.
It’s also common to add Prettier as a pre-commit hook, so it always formats your code before you commit.
You can run it on the test step of your CI build using the --list-different flag, so it fails if any of the files isn’t using Prettier format.
There’s also an online tool that may come handy for quick formatting without any set up.
ESLint and Prettier
One common misconception is that Prettier can replace a linter like ESLint. It can’t and it shouldn’t.
It can replace some of ESLint rules concerning styling. The goal of these rules is mostly to enforce consistency across the codebase, and you won’t need them if you are using Prettier.
You can use eslint-config-prettier to use any ESLint config you want and turn off all rules that may conflict with Prettier .
But there are also linting rules that detect anti-patterns and potential mistakes. These are the best kind of rules, it’s like someone adding tests to your project for free. This is where ESLint shines.
That said, Prettier will still highlight some of your mistakes. It won’t remove bugs from your code (because the AST will be the same) but it can make them easier to find.
For example, ESLint has a rule that detects escaping of non-special characters, it catches a common mistake when using regular expressions: RegExp("\d").test("6"). Prettier will print this as RegExp("d").test("6"), making it much easier to see that what you were trying to write was RegExp("\\d").test("6"). True story.
Enforcing a comprehensive style and avoiding stylistic debates
For many, the best thing about Prettier is how it removes the burden of building and enforcing a style guide from the team and leaves it to a tool.
It’s too common to see code reviews taking longer because of stylistic issues, or files where the style depends on the last developer that committed a change or which editor they used, or projects where the team didn’t even tried to build a style guide because of the work it takes.
Prettier aims to reduce all those problems to a minimum.
Curing the formatting fatigue
Because Prettier can instantly format your code with a single keystroke, you can focus 100% on the code and give zero thoughts about formatting.
The more you use Prettier the less you are distracted about formatting. You may not realize how good this feels until you experience it. For me, this is the best part of using Prettier.
Openness to newcomers
Another benefit of leaving the whole code formatting to an automatic tool is that people that are not familiar with the style guidelines have one less thing to worry about. This applies to people used to different guidelines but it’s even better for people who are new to JavaScript.
Opinionated
Prettier is heavily opinionated. That means it has few options, if you don’t like how it formatted something there isn’t much you can do. The few options it has are mainly to stay neutral in holy wars like tabs vs spaces or semicolons vs no-semicolons.
Let’s see one of the many example where you can’t configure the output. Prettier format this pattern:
to:
For this case, I like better the unformatted code. But, frankly, I don’t care, I’ll get used to it. Knowing that whatever I write will be made consistent with the rest of the codebase is more than enough to make me adopt different patterns. In the case that the code is made objectively less readable, that’s probably a bug so please report it.
JavaScript and friends
These days it’s hard to have a project where pure JavaScript is the only language. So Prettier is adding support for more flavors with each new release. Currently (v1.5) it supports: ES2017, Flow, TypeScript, JSON, JSX, CSS, LESS, SCSS, CSS-in-JS (styled-components and styled-jsx), and GraphQL.
Conclusion
Prettier made me a 10% happier programmer.
If you haven’t tried it yet, consider giving it a try and let me know how it goes. If you use it and like it, help more people discover it (for example, sharing this post 😉). If you used Prettier and stopped, I’m curious, why?
Thanks for reading.
