/ ES6

Write code. Don't fight your linter.

Stop wasting time formatting javascript!

Discussions About Building and Enforcing a JavaScript Style Guide

By far the biggest reason for adopting prettier is to stop all the ongoing debates over styles. It is generally accepted that having a common style guide is valuable for a project & team but getting there is a very painful and unrewarding process.

People get very emotional around formatting issues and linters, and nobody likes spending time fixing their linter configuration or the errors displayed. Formatting your code is very important, especially with JavaScript libraries like React. It's also a good standard practice for conformity amongst teams.

Feedback from research:

"One may think that it's only useful for people with very limited programming experience. We've seen the ramp up time from experienced engineers joining the company, as they likely used a different coding style before, and developers coming from a different programming language."

Reasons to use prettier

"Prettier is usually introduced by people with experience in the current codebase and JavaScript but the people that disproportionately benefit from it are newcomers to the codebase."

  • “I always put spaces in the wrong place, now I don't have to worry about it anymore.”
  • “When you're a beginner you're making a lot of mistakes caused by the syntax.
  • Thanks to Prettier you can reduce mistakes and save time for focusing on what really matters.”
  • “As a teacher, I will also tell to my students to install Prettier to help them to learn the JS syntax and have readable files.”

Write code. Don't fight your linter.

"What usually happens once people are using prettier is that they realize that they actually spend a lot of time and mental energy formatting their code. With prettier editor integration, you can just press that magic key binding and poof, the code is formatted. This is an eye opening experience if anything else."

  • “I want to write code. Not spend cycles on formatting.”
  • “It removed 5% that sucks in our daily life - aka formatting”
  • “We're in 2017 and it's still painful to break a call into multiple lines when you happen to add an argument that makes it go over the 80 columns limit.“

Easy to implement

"We've worked very hard to use the least controversial coding styles, went through many rounds of fixing all the edge cases and polished the getting started experience. When you're ready to push prettier into your codebase, not only should it be painless for you to do it technically but the newly formatted codebase should not generate major controversy and be accepted painlessly by your co-workers."

  • “It's low overhead. We were able to throw Prettier at very different kinds of repos without much work.”
  • “It's been mostly bug free. Had there been major styling issues during the course of implementation we would have been wary about throwing this at our JS codebase. I'm happy to say that's not the case.”
  • “Everyone runs it as part of their pre commit scripts, a couple of us use the editor on save extensions as well.”
  • “It's fast, against one of our larger JS codebases we were able to run Prettier in under 13 seconds.”
  • “The biggest benefit for prettier for us was being able to format the entire code base at once.”

Cleaning up your codebase

Since coming up with a coding style and enforcing it is a big undertaking, it often slips through the cracks and you are left working on inconsistent codebases. Running prettier in this case is a quick win, the codebase is now uniform and easier to read without spending hardly any time.

  • “Take a look at the code. I just need to restore sanity.”
  • “We inherited a ~2000 module ES6 code base, developed by 20 different developers over 18 months, in a global team. Felt like such a win without much research.

Staying current

It's the latest shiny tool for styling JavaScript code.

This is being widely adopted very quickly.

Purely technical aspects of the projects aren't the only thing people look into when choosing to adopt prettier. Who built and uses it and how quickly it spreads through the community have a non trivial impact.

Tooling and Editor Integration

ESLint contains many rules and those that are formatting-related might conflict with Prettier, such as arrow-parens, space-before-function-paren, etc.

Using them together will cause some issues. The following tools have been created to use ESLint and Prettier together.


Runs prettier then run eslint --fix on the code. eslint usually has automatic fixes for formatting related rules, and eslint --fix will be able to fix the conflicting formatting introduced by Prettier. You will not need to run the prettier command separately.


eslint-plugin-prettier: This is an ESLint plugin, meaning it contains implementation for additional rules that ESLint will check for. This plugin uses Prettier under the hood and will raise issues when your code differs from Prettier's expected output. Those issues can be automatically fixed via --fix.

With this plugin, you do not need to run the prettier command separately, the command is being run as part of the plugin. This plugin does not turn off formatting-related rules, and you will need to turn them off if you see conflicts for such rules either manually or via eslint-config-prettier.


eslint-config-prettier: This is an ESLint config, and it contains configurations for rules (whether certain rules are on, off, or special configurations).

This config allows you to use Prettier with other ESLint configs like eslint-config-airbnb by turning off formatting-related rules that might conflict with Prettier. With this config, you do not need to use prettier-eslint as ESLint would not complain after Prettier formats your code. You will however, need to run the prettier command separately.

Hope this sums up the differences.

Editor Plugins



Seth Bergman

Seth Bergman

I'm a Software Engineer focused on helping companies scale. I love learning about software architecture, containers, open source programming and automation.

Read More