Becoming Prettier

In this post I will talk about how a program called Prettier can speed up your team and get rid of formatting nit picks in code review.

Before we start talking about Prettier, I want to talk about linting. Linting is when you run a program that analyses code you have written and identifies problems with it before it is compiled or run.

The name linting comes from a program written by Stephen Johnson in the 1970s, that was used to find common problems in C code that could prevent it from compiling.

Today we use linting loosely to describe any process that analyses code before it is run for syntax errors or ugly formatting, but most importantly common mistakes that are likely to produce errors, confusion, or surprises.

Usually when we check formatting using a linter, there is a plethora of rules to configure, and once you configure it as you like, aligning the team on it and making you all fluid in your ruleset might be painful.

Prettier tries to solve the above annoyance. It is an opinionated tool that reads your code and reformat it automatically. Lets take a look at how it works.

I have created a valid, but poorly formatted React component.

Now I’m going to run npx prettier src/CharacterCount.jsx on the file. (npx is a command bundled with NPM 5.2 that will automatically execute a binary package.)

As you can see, Prettier has cleaned the file up and applied what it thinks is the best formatting for the syntax.

I loudly applaud this. We want nice formatting when we read code, but to spend time on actually formatting the code is wasting time. Getting rid of the change / lint / change / lint workflow to fix formatting problems is a blessing.

Most editors integrate with Prettier. In Sublime Text all I did was install JsPrettier from inside Sublime and that gave me access to a command that will format the current file. Before this you should install Prettier globally with npm install -g prettier or yarn global prettier.

So, how does Prettier do this? There is a program called ESPrima that you might have seen it as a dependency when using NPM sometime. It stands for ECMAScript parsing infrastructure for multipurpose analysis and it’s a tokenizer for JavaScript which job it is to create a syntax tree from JavaScript.

Prettier does this, then abolishes all your formatting, and reformats it according to its ruleset.

If you want to understand better what a syntax tree looks like and how it behaves, you can check out AST Explorer pictured above, where you can play around with it on the fly. It also has the Prettier formatter built in.

If you decide to use Prettier on your project or with your team, you can add a hook to Git that checks everything in staging, but I prefer to do it manually by running prettier ‘*/**/*.{js,jsx} --write using an NPM script.

{
  "name": "becoming-prettier",
  "scripts": {
    "format": "prettier '*/**/*.{js,jsx}' --write"
  },
  "dependencies": {
    "prettier": "^1.7.4"
  }
}

I think the ideal solution would be to automate this in your Continuous Integration suite, however, it requires some PR discipline that is extremely opinionated and I can’t vouch for any specific solutions. But let me outline the problem. If you would to auto-format on Travis or Circle CI, the integration runs would have to commit to the pull request. This might conflict with a developers way of committing. Each commit in the pull request that had formatting errors would now be dependent on the auto-formatting commit, preventing easy reverts. However, if your team decided that all PRs are squashed before commit, and you see all PRs as atomic changes, then it would work fine for you.

I love that Prettier can remove some pointless opinions from development, but I wish there was a tool that went even further, and was extremely opinionated about not only formatting, but standards too. ESLint can be used for this, but in my opinion ESLint has so many options it can be difficult to start using it on a project which has many contributors and lots of work in progress.