Should you replace prettier? Maybe

For years, I've been prettier's biggest fan... Introducing it to every codebase at a new role, instantly adding it to any new repository, installing additional plugins such as tailwind or xml and of course, ensuring the "Format on save" option is switched on.

But recently while building algovi I encountered some turbulence for the first time with my first love of formatting.

The source of this frustration? Multiple operators.

Consider the following:

const result = a + b * c - d / e;

To understand it, you need to recall operator precedence.

Perhaps most developers would prefer:

const result = (a + (b * c)) - (d / e);

Is it uglier? Depends who's answering. However, most of us would agree it's more readable.

Alas, when it comes time to format, the parentheses are nowhere to be found.

This example may be trivial, but it's easy to see how this problem can get worse.

The solution?

I don't have a good one...yet.

My first thought was to use no-mixed-operators, which can be setup to enforce parentheses on any operator you like.

However, after setting it up. I noticed my prettier eslint rule was still complaining (yes I did make sure the rule sat after my prettier rules). After some digging I found this comically long issue where some developers resolved to stop using prettier entirely.

Why?

The only way to get prettier to play nice with this rule is extraction:

const mult = b * c;
const div = d / e;
const result = a + mult - div;

It's not terrible. Potentially it's actually preferable for longer equations. For my use cases though, it breaks the flow of the equation. Sometimes, wrapping segments in parentheses communicates intent without polluting the namespace with throwaway variables.

Potential solutions

The only realistic solutions for my use case I found are to replace prettier for js/ts altogether, leaving it to format css, markdown etc. which I'm not eager to do.

@stylistic/eslint can be configured to pretty much replicate prettier's behaviour, but I'm an all or nothing guy. If I'm going to add an extensive plugin I'd like to use it properly, replacing my react and typescript rules with it as they recommend. I will probably get round to this when I have the time, updating my core eslint config

biome is a replacement for both ESlint and prettier. It's a pretty cool project but I've already spent considerable time setting up my ESlint so this is not a realistic option.

In defence of prettier

If you have a more complex equation:

const result = a + b * c ** d / e - f % g << h & i | j && k || l;

Prettier will format it closer to what I am suggesting above:

const result =
      (((a + (b * c ** d) / e - (f % g)) << h) & i) | (j && k) || l;

This is a case for extraction though. Because similarly to ternaries, there are diminishing marginal returns on parenthesis.

Closing thoughts

Prettier has been an essential tool for me for years.

However, this experience has brought me to the conclusion that code formatters should aid readability, not rigidly enforce minimalism at the cost of comprehension. Until Prettier allows an option to respect extra parentheses for clarity, we are stuck choosing between formatter compliance and readable math. Does a formatter deserve to have this much power?