What is an example of a Prettier rule that can't be done in EsLint?

I am curious, I see comments like this...

> As mentioned earlier, whereas Prettier takes care of your code formatting, ESLint takes care of your code style. The former does everything automatically for you. If you have set up Prettier, you can configure it to format your file on saving it. That way, you never need to worry about your code formatting anymore. Since Prettier is highly opinionated, you can do only minor configurations.
>
> The latter, ESLint, isn't intended to perform code style fixes automatically though. Instead, ESLint warns you about code smells

But clearly there is a lot of work being done by intended here for example eslint can handle plenty of stylistic stuff like line length, indent, new lines, etc

In fact most of the stuff I see here has an eslint alternative. So why would I use prettier if I already use lint? What are the examples of prettier specific enforcement of styling?

For some rules you mentioned, namely indent or new lines, it doesn't matter, both ESlint and prettier lead to the same result. However max-len and printWidth work significantly different. max-len will just count the number of characters and throws an error if it's exceeded, but the error needs to be manually fixed.

According to the prettier docs, here is how the printWidth option works in contrast:

> Prettier’s printWidth option does not work the same way. It is not the hard upper allowed line length limit. It is a way to say to Prettier roughly how long you’d like lines to be. Prettier will make both shorter and longer lines, but generally strive to meet the specified printWidth.

Additionally, prettier automatically fixes the line length of your lines. For example, see the following code:

function myVeryCoolFunctionWithLongName(myFirstFunctionArgument, mySecondFunctionArgument, myThirdFunctionArgument) {
}

With default prettier settings, it will be changed to:

function myVeryCoolFunctionWithLongName(
  myFirstFunctionArgument,
  mySecondFunctionArgument,
  myThirdFunctionArgument,
) {}

Whereas ESLint would just throw an error.

To summarize, while ESLint does a decent job in detecting formatting issues, prettier is much smarter in fixing your code to meet a consistent format. Read very closely again the sentence you cited:

> ESLint isn't intended to perform code style fixes automatically

Further reference:

• ESLint froze stylistic rules as of May 2020
• TypeScript ESLint encourages using prettier for formatting

As prettier docs mentioned:

> 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!
>
> In other words, use Prettier for formatting and linters for catching
> bugs!

In fact, prettier will do it faster and more predictable because it is designed to do so.
If you use ESLint for formatting, it would be like using a 5 pound hammer to drive a nail.

Use the right tool for the right job

I highly recommend you watch the video of Theo on this subject.

See more:

• Josh Goldberg - Setting Up ESLint and TypeScript for React
• Integrating with Linters