Prettier + ESLint + Facebook Code Quality: The Auto-magical Code Styling Tutorial

Never worry about code styling again

E.J. Mason
Space Cats
Published in
6 min readJul 19, 2017

--

I’ll admit, I spend way too much time obsessing over code formatting and code-quality. I have my coveted set of ESLint rules, a slew of obnoxious plugins in my code editor, and some pretty nasty pre-commit Git hooks that would make a person the world record holder for speed-typing “ — no-verify”.

It can eat up precious time (like optimizing webpack), but styling and code quality are important for a number of reasons:

  • Having consistent and clean code makes you look like a better coder. Many companies have issues with technical debt. If you are looking to get hired, they want engineers that won’t exacerbate that problem.
  • When code is more readable it speeds up the development process. Once the brain gets used to code formatted a certain way, it becomes much easier to figure what is going on.
  • Best practices enforced by code-quality increase performance. Javascript can do some weird stuff. It is the wild west of code languages. Let a linter take care of that headache.
  • Other benefits

Quick overview of the tools

  • Prettier takes care of all the formatting. It makes code look nice. The best part is that it does everything for you.
  • ESLint takes care of the code-quality. These rules catch bugs and enforce best practices.
  • Linting rule sets, plugins and extensions tell us what the rules are.
  • Git hooks auto-magically take care of some tedious stuff.

Step 1: Integrating Prettier and Automating Code Styling

Prettier Github Repo & Documentation

Prettier is an opinionated code formatter that will reprint your entire codebase so it conforms to your styling preferences. Once installed, you don’t ever have to think about styling again. The best part is it just works! You can push a button and all your code instantly looks professional. The logic lives in your package.json so no hounding teammates to install linters and githooks! Woohoo!! Lets get to it:

Installation

yarn add prettier --dev

Personally, I wouldn’t install it globally. It makes more sense to add it where you need it. Add it on a per project basis.

Usage

Once installed an NPM script can be created to use the CLI. Here is a very basic script that formats your code, with a single rule change:

prettier --single-quote --write "src/**/*.js"

Now lets do some magic:

Step 2: Husky + Lint-Staged to automate prettier with Git Hooks

Husky simplifies githooks, running a subroutine before adding to version control.

Lint-Staged and Husky go together like peas and carrots. It creates a script run against files that are ‘staged’ or ‘added’ in Git. Now prettier doesn’t need to parse your entire codebase; only the files that have changed.

Installation

yarn add husky lint-staged --dev

Add the precommit script to your package.json.

"scripts": {
"precommit": "lint-staged"
},

The lint-stage script needs to be declared in your package.json. I left the precommit script in the example below to see the depth of the “lint-staged” script and how they work together.

{
"scripts": {
"precommit": "lint-staged"
},
"lint-staged": {
"*.js": [
"prettier --write",
"git add"
]
}
}

Note: There may be some formatting rules that you may want to change. For instance, I like single quotes and trailing commas after all my object properties. If you want to get weird, the prettier docs list all the possible options to add to your script.

Now that our code looks pretty ¯\_(ツ)_/¯ , lets set up code-quality rules.

Step 3: Eslint, the code police

Linting is a vital tool in any programming language. When learning to code, it can prevent bad habits from forming.

ESLint is a popular tool for javascript developers. One great advantage; it is highly configurable. Even though opinionated libraries can be easier, ESLint’s customizability enables it to play nice with others. If you aren’t familiar with ESLint there are a lot of resources out there and their website has some really great documentation.

First, install ESLint locally. Again, I don’t like installing it globally since I have to install all the plugins globally too. It also ensures the latest versions are being used.

yarn add eslint --dev

Integrate ESLint with your code editor. For VS Code install the ESLint Extension.

Follow the extension documentation. It will use your ESLint settings defined in your project to provide feedback when your code has errors. When looking for a configuration it looks first in your project, then globally.

Create the ‘.eslintrc.json’ to define the project’s eslint settings.

// run this command in the terminal:./node_modules/.bin/eslint --init// Or you can just add a .eslintrc.json to your project//Note: you may also want to add a .eslintignore . It works just like a .gitignore

There are many preconfigured style guides that integrate with ESLint:

  • Airbnb Style guide is really popular for React.
  • Johnpapa is what I hear a lot for Angular
  • Standard is popular, but very opinionated. You can’t change anything so it can be hard to integrate with other tools.

Step 4: Configuring ESLint to bend to our will (with React)

The majority of my community likes React so this section is specific to it. Sorry Angular guys.

Since we only care about code-quality rules, we don’t need any of the robust configurations above. Lucky for us, Facebook created a set of rules that have no styling opinion. The react-app configuration is hidden in the depths of Facebook’s create-react-app repository. Best part: it only enforces code quality. Prettier should marry this configuration.

Install the plugins & extensions.

yarn add --save-dev eslint-config-react-app babel-eslint eslint-plugin-flowtype eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react

For information on each of these configurations, you can google them to see all the rules.

Adding the extentions and plugins to ‘.eslintrc.json’

{
"extends": ["react-app", "plugin:jsx-a11y/recommended"],
"plugins": ["jsx-a11y"]
}

Step 5: Configure ESLint to play nice with Prettier

Since we have rules coming from ESLint and Prettier, we need to make sure that we don’t have rule conflicts. This is especially important if you want to use Airbnb or Standard styling.

  • eslint-config-prettier: Turns off all rules that are unnecessary or might conflict with prettier.
yarn add eslint-config-prettier --dev

Now add the plugins and rules to your .eslintrc:

{
"extends": [
"prettier",
"prettier/flowtype", // if you are using flow
"prettier/react"
]
}

Check out the eslint-config-prettier documentation for more details.

Step 6 (Optional): Other personal configurations

These steps aren’t crucial, but this information can be useful.

Add the prettier ESLint plugin to see formatting errors

  • eslint-plugin-prettier gives you the ability to see feedback in your code editor when styling is incorrect. It’s not important, but some people like to see that.
yarn add eslint-plugin-prettier --dev

Now add the plugins and rules to your .eslintrc:

// .eslinrc.json{
"plugins": [
"prettier"
],
"rules": {
"prettier/prettier": "error"
}
}

To further configure this see the eslint-plugin-prettier documentation

Other notable libraries to use with prettier:

Bonus Note: VS Code Prettier Extension

There is an extension for code editors that can be configured to format your code on save. I tried using it for a while, but soon realized I didn’t like it. The rules are set in the VS Code settings, which can be a pain if two projects use different rules. (Obviously there are ways to deal with this, but it didn’t seem ideal to me). It also will format your code in whatever file you are working on and has caused some issues for me with some open source I have been working on. This one is all personal preference.

Now your team is set up to effortlessly create a codebase that looks professional and clean. I would love to hear about any other tools you guys have used to enforce styling and quality in your projects!

Hardcore Mode

For those that want to take this to the next level, there are tools that can lint code on pull requests sent to your organization on Github. I have no idea which is the best one, but a simple google search can get you on the right track.

TL;DR

  • Formatting code is important
  • Add prettier to your project dependencies so code can be formatted automatically
  • Add husky and lint-staged to project dependencies and create a precommit script in your package.json, requiring everyone to conform to the same style, painlessly.
  • Add ESLint to your project dependencies and add the .eslintrc configuration file to define code-quality rules
  • Add an ESLint styling configuration. For React and prettier, use the Facebook ESLint rules: eslint-config-react-app
  • Add any other config or plugin so your linting rules don’t conflict.
  • Add the ESLint Extension to your code editor to get visual feedback about linting errors
  • Look gud

--

--

E.J. Mason
Space Cats

Honestly, is there a cooler place to work than building software? Sharing better ways to build software. If you think your way wins, I want to know it!