Prettier and the Beauty of Opinionated Code Formatters
Tags: javascript, productivity, beginners, codequality
Published: 2020-06-24 18:22:36

I love [Prettier](https://prettier.io/).

It's probably the single tool that has had the biggest effect on my productivity as a programmer (after Git, maybe).

For those of you that don't know, Prettier is an opinionated code formatter for Javascript/Typescript, HTML, JSX, and more.  It is lightweight, requires next to no configuration, and automatically formats code for you.  Gone are the days where you spend half of your day arguing with co-workers how to nest HTML, what the correct line length is, or whether strings should have single vs double quotes.

This is my Prettier configuration:

```jsx
module.exports = {
  printWidth: 80,
  singleQuote: true,
  trailingComma: 'es5',
};
```

Isn't that simple?  My settings are a bit opinionated so you can get by with even less!

I use VSCode, so I setup all my projects to format on save.  I strongly recommend you do the same if you haven't already.  Any modern IDE should have this capability.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/y2bep355jozw37iy0im0.gif)
*There is a strange pleasure in seeing your garbled JSX fit perfectly into place on save.*

# The Rise of the Opinionated Formatter

Opinionated formatters are great because they eliminate the ongoing flame war nerds and programmers love to have about code formatting.  While it's good that we care this much about the quality of our code, overall this is a huge waste of time.  Since we started using Prettier on my team, pull request reviews are much more effective and we're no longer having stylistic discussions every. single. week.  

We need to start valuing our time more and realize these discussions are a waste of time.  While you may be right that God's intention for strings is to use double quotes, **it really doesn't matter**.  The benefit of using them is already outweighed by the time you've wasted discussing it.  Leave that discussion and mental baggage to the Prettier team, I promise they've already [given plenty of thought](https://github.com/prettier/prettier/blob/master/CHANGELOG.md) to what the best defaults are.

Prettier is not the only code formatter out there.  For Python, I use and love [Black](https://pypi.org/project/black/).  Check out [this Github repo](https://github.com/rishirdua/awesome-code-formatters) for alternatives in other languages.

# How to Enforce Prettier

There are many ways to enforce Prettier on your team besides having everyone set it up in their IDE.  If you are purely a frontend team, you can use [husky and lint-staged]( https://prettier.io/docs/en/precommit.html).  If you are working on a full-stack or multi-language team, you can use the [pre-commit Python package](https://prettier.io/docs/en/precommit.html#option-3-pre-commithttpsgithubcompre-commitpre-commit) to run Prettier as a pre-commit hook.  That means that any staged files will be Prettified when you commit using git.

# Do we need Additional Linting?

In the past, I used [ESLint](https://eslint.org/) heavily in my frontend projects.  Especially with [Airbnb's configuration](https://github.com/airbnb/javascript), which tends to be very strict.

The problem with ESLint is that it's too configurable.  It doesn't solve the stylistic flame war.  It just ends up adding options, which we really need *less* of.  As web developers we already suffer from [decision fatigue](https://en.wikipedia.org/wiki/Decision_fatigue), having to choose between frameworks, 3rd party libraries, state management, different styling options, REST vs GraphQL, build tools, etc.

*An example of ESLint decision fatigue from a real project:*
```jsx
rules: {
  'react/no-unescaped-entities': 'off',
  'no-restricted-syntax': 'off',
  'no-continue': 'off',
  'no-underscore-dangle': 'off',
  'operator-linebreak': 'off',
  'implicit-arrow-linebreak': 'off',
  'react/destructuring-assignment': 'off',
  'react/no-multi-comp': 'off',
  'jsx-a11y/click-events-have-key-events': 'off',
  'jsx-a11y/no-static-element-interactions': 'off',
  'react/jsx-one-expression-per-line': 'off',
  'lines-between-class-members': ['error', 'always', { exceptAfterSingleLine: true}],
  'react/no-array-index-key': 'off',
}
```

ESLint rules are often arbitrarily turned on/off based on people's opinion.  Either that or you need a whole README devoted to why certain rules are enforced and others are not.  Every time you bring on a new developer you are then opening up these decisions to question.  This is too much unnecessary mental drain on everyone.

Most of what ESLint enforces is not automatically fixable, unlike Prettier.  This makes it clunky to run in CI or as a pre-commit hook.  It requires a developer to go and try to fix it themselves, creating additional manual work.  Fixing linting issues is not the fun part of coding.

I still think ESLint has some uses, however with Prettier I think those are pretty minimal.  My configuration now basically just extends [eslint-config-react-app](https://github.com/facebook/create-react-app/tree/master/packages/eslint-config-react-app) (used by [create-react-app](https://github.com/facebook/create-react-app)) and [eslint-prettier](https://github.com/prettier/eslint-plugin-prettier) (to avoid conflicting Prettier and ESLint rules), and I don't touch any extra rules.  I could see myself getting rid of it eventually as Prettier matures.

My `.eslintrc.js` now looks like this:
```jsx
module.exports = {
  extends: [
    'react-app',
    'plugin:prettier/recommended',
  ],
}
```

*Simplicity is underrated.*

# What about you?

Have you found Prettier or opinionated formatters to be as useful for yourself and your team?  Do you think ESLint (or additional linting) is necessary and conducive to productivity?