Thoughts about using prettier

Many of us have been using prettier for a while now and have found it wonderful for formatting code.

Prettier obviously doesn’t replace most of the lint rules in Airbnb’s style guide (c.f. #1307), but it can definitely compliment it by freeing up a developer to not have to worry about code style (where should line breaks happen, how much should this be indented) and instead worry about more important things (like not using for-of #1122). The prettier website has a bunch of other people’s reasons why they like prettier.

Obviously people can use prettier with Airbnb’s style guide currently (as many of us have been), but I was wondering if Airbnb had considered making this the default.

[aboyton]

Thanks for the quick reply. Unfortunately this reply is not nearly so short 😢

1. I definitely wasn’t suggesting prettier would replace airbnb’s style guide (as others have claimed and you realised that I wasn’t), but that you could allow prettier be part of it. To quote from the How does it compare to ESLint section of their website:

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style…

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it’s not possible for the programmer to make a mistake there anymore 😃

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors…

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

Instead I’m simply recommending extending eslint-plugin-prettier and either manually disabling all the rules which conflict (or by using the list from eslint-config-prettier but I’m guessing you’d prefer to be explicit rather than depending on another list).

---

1. We’ve found using Airbnb’s style guide freed us as a company from having the internal arguments about style which was great. No longer did we need to waste brain power arguing about if we should object-shorthand or dot-notation, we could let you worry about that for us.

We’ve been using Airbnb’s style guide with eslint-plugin-prettier and eslint-config-prettier for a couple of months now on a few hundred thousands of code in our codebase and have found it to be a very similar experience of freeing the mind to worry about more important things. It’s hard to describe, but not needing to worry about whitespace (which is really all prettier does) has allowed me to concentrate better on the actual code that I’m writing. I’d highly encourage you to try it. Many in the company were highly dubious at first but were quickly won over.

---

1. Technically there’s absolutely nothing that prettier can do that you can’t do with ESLint, precisely because the lint rule eslint-plugin-prettier does exactly that. You can simply consider prettier as a souped up indentation and line break lint rule (it does a couple of extra things with parens).

That said, that’s a bit of a cheats argument and I’m guessing not what you were after.

The indentation rule in ESLint has gone through massive rewrites in ESLint 4. That said, it still won’t say that

// good
foo(arg1, arg2, arg3, arg4);

// bad
foo(
  arg1,
  arg2,
  arg3,
  arg4,
);

// bad
foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

// good
foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

This is the trivial example often cited, but it goes much further, how do you break up ternaries on multiple lines, how do you indent arrow functions in big promise chains, etc. With prettier I don’t need to remember, I just hit save and it reformats it in a way that looks pretty good.

I used to think that developers should worry about all aspects of code style, but having tried prettier for a few months now I’m glad to now have to worry about it.

---

1. Let me try my best. Prettier tries really hard to have as few options as possible (there’s a fork that adds more, but I’d argue that’s missing a lot of the point of not worrying about style).

The only two options you’d need for prettier are --single-quote and --trailing-comma all.

It’s hard for me to know exactly what is different between using prettier to manage “style” and airbnb’s rules. One way to see the differences would be to study the source code of eslint-config-prettier.

Another way (what I’ve done below) is see the practical differences we have on our codebase between the two. Please note that we don’t use JSX and so I can’t speak of any differences there.

Running prettier over our codebase for the first time reformatted a lot of whitespace changes that Airbnb’s style guide didn’t enforce. As for actual differences (as in places where the two disagree), the main one we found in our codebase (by number of lines) is:

// airbnb (kinda)
const foo = function (arg, arg2) {

// prettier
const foo = function(arg, arg2) {

That said, 7.1 of the airbnb style guide forbids function declarations like this, we just haven’t cleaned all of ours up yet 😰.

As for the actual differences, these are all that I have found:

/// space-in-parens
// airbnb
for (let i = 0; i < foo.length;) {

// prettier (note extra space after the last `;`
for (let i = 0; i < foo.length; ) {

// wrap-iife
// airbnb
(function init() {
  // Body
}());

// prettier
(function init() {
  // Body
})();

// indent
// airbnb
const foo = bar
  ? ''
  : {
    property,
    anotherProperty,
  };

// prettier
const foo = bar
  ? ""
  : {
      property,
      anotherProperty
    };

// indent
// airbnb
this.foo
  .getStuff(
  {
    bar
  },
    {},
  )
  .then()

// prettier
this.foo
  .getStuff(
    {
      bar
    },
    {}
  )
  .then();

One more that I will add is that is seems that using eslint-config-prettier means that the following seems to be enforced. I haven’t worked out exactly where that’s coming from as it’s not prettier as you can see from the playground

// no-confusing-arrow
// airbnb
foobar = someList.reduce(
  (foo, bar) => { return bar === '' ? foo : bar; },
  '',
);

// prettier with eslint-config-prettier?
foobar = someList.reduce(
  (foo, bar) => (bar === '' ? foo : bar),
  '',
);

So to summarise, the conflicts between the two style guides all seem very minor and I do think that adding prettier as an ESLint rule would actually work really well as part of Airbnb’s style guide. That said, it’s not my guide, so all I can do is ask you to consider it.

[rattrayalex]

@ljharb is that feasible with the current eslint autofix primitives? See eg this comment from the eslint repo owner.

Given the core functionality of prettier - line length - I’m not sure that any eslint fix could be made in a form other than “run prettier and use it as an eslint rule”, which is what eslint-plugin-prettier accomplishes.

It might be worth your time to experiment with the tool; I think you may find it interesting.

Perhaps Airbnb could fork prettier, and align its output with your own style. I imagine it would be popular.