Search code examples
eslintprettiertypescript-eslintprettier-eslint

"@typescript-eslint" recommends the Prettier for the stylistic issues, but has the Prettier same rules and options as ESLint?

From the @typescript-eslint documentation:

Suggested Usage - Prettier

Neither typescript-eslint nor ESLint core enable any formatting-related rules in any recommended presets. However, some third party plugin configurations may still enable that bad practice.

If you see formatting rules enabled in your ESLint configuration, we recommend using eslint-config-prettier to disable formatting rules in your ESLint configuration. You can then configure your formatter separately from ESLint.

https://typescript-eslint.io/linting/troubleshooting/formatting

Reading this I expected that Prettier provides the deeply customizable rich rules set fully covering the stylistic rules of ESLint and its plugins like @typescript-eslint. I was unpleasantly surprised when read the "Option Philosophy" of Prettier:

Prettier is not a kitchen-sink code formatter that attempts to print your code in any way you wish. It is opinionated.

https://prettier.io/docs/en/option-philosophy.html

Does it mean that some of Prettier rules could not be overridden? (I have already knew that the specific Prettier rules could not be disabled).

The Prettier's options count is small, and also the options could not be applied selectively. So, what it means? "We recommend you to use the Prettier for the stylistic issues, but from now the Prettier will decide how you must to write the code."? If so, I am not fine with it...

P. S. To all Prettier fans: please do not waste your time to convince me to use the Prettier and obey to rules which has been decided by Prettier developers - I am not the one who "acting like everybody".

Solution

  • There are other options - such as:

    • dprint which is a very customisable formatter written in rust,
    • rome which is still reasonably new, and I believe is intending to be more of a tooling ecosystem rather than just a single tool you can use.
    • numerous prettier forks that offer differing levels of customisability,
      • You'll need to do some digging to find one that's currently being maintained and is up-to-date - the problem with formatters is that they are a lot of work to build and maintain, so without a big community they often fall out-of-favour.

    As for why we (the TypeScript-ESLint team) recommend prettier because:

    1. it is by far the most popular and prevalent JS code formatter out there (~29.5m downloads, almost as many as ESLint itself has)
    2. it is pretty easy to setup and use (most codebases could get away with just doing npx prettier --write src).
    3. it is (from our experience) the most consistent formatter with the fewest edge-cases.

    The biggest reason why prettier hits these 3 points is because it's so opinionated and non-configurable - if you hop into a repo that uses prettier then you will know almost exactly what the code looks like.

    It can achieve this because it has so few options. In a nutshell each option can double the amount of test cases required - which is harder to build for and maintain, making it easy to introduce edge-cases which lead to inconsistent or broken formatting. So fewer options means fewer tests which means it's easier to maintain and catch edge cases.

    For more additional context on why we (the TypeScript-ESLint team) strongly recommend against using stylistic formatting rules - formatting your code should be about making the code more consistent and to remove the cognitive overhead involved with writing code - instead of thinking about how your code looks, you should be spending that time and energy thinking about the problem you're trying to solve.

    Unfortunately the fact of the matter is that formatting lint rules are not very powerful, nor do they enforce a high degree of consistency. For example the indent lint rule has so many missed cases that it really doesn't enforce a useful style. This inconsistency means that you do have to consciously think about how your code looks on top of reacting to whatever formatting lint rules fire on your codebase.

    Put another way - whilst you do get a very, very high degree of customisation with lint rules, you get a very, very low degree of consistency.

    Anecdotally I used to be the sort of person that lived and breathed lint rules for formatting - I had a large, custom config I built with my team to format our code. When I first tried prettier - I actually hated it - it put everything in weird places that I wasn't used to and stopped me formatting code how I wanted! It only took me about a week to do a complete 180 - I fell in love with prettier. Once I stopped fighting prettier I figured out that it enforces so much more than the lint rules ever did and it was so easy to apply automatically because it was a separate tool (so no risk of accidentally applying a different rule's fixer like with eslint --fix).

    It took a bit more time to get fully used to the format, but now I find it very easy to read and write code formatted by prettier because no matter the codebase it always looks the exact same!