does that require a config?

depends, will you keep finding pendatic faults after any answer?

Having a typo in "pendantic" is a masterstroke

> "pendantic"

Genius!

One more time and it's pentadic. But imagine someone finding a way to bikeshed anti-bikeshedding tools. "Take with food."

Seeing that my comment was against pedantry, no contradiction there!

I come from go where this stuff is default

No, it has good defaults. See also: https://prettier.io/docs/option-philosophy

Good to someone, somewhere, telling everyone else what good is.

Arguably, code formatters should be configurable, to get a format for your code that you want. Unfortunately, prettier isn't one, and it is a form of regression in many communities at the cost of choice pruning.

It might be great for a CI pipeline for constraining how code should look (use prettier, dumbass!), but it isn't great for actually formatting code, as it just makes the code "prettier".

Using it as a precommit hook in OSS projects makes it so that people can write code however they want. But it ends up in the repo following the guidelines of the repo. Minimizing unnecessary back-and-forth with PRs. Extremely useful in my opinion.

Even though prettier has defaults, but they can be modified to quite some extent to suit your projects needs: https://prettier.io/docs/options

> Using it as a precommit hook in OSS projects makes it so that people can write code however they want.

That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around).

> quite some extent

Not really, and I have written prettier plugins to get around that constraint.

IMO, its not great, which is kind of how things work out when you try to do everything in one project.

> That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around).

No arguments here. You are free to choose the formatter you want.

> Not really, and I have written prettier plugins to get around that constraint.

Or you could simply use those better formatters you were talking about.

I moved on to Biome (which replaces both ESLint and Prettier) and while the IDE extensions have been a bit buggy, it's much faster and has fewer dependencies. It was always a pain to set up ESLint + Prettier.

ESLint these days doesn't have any styling related lints (unless you opt into them) which means that it works out-of-the-box with Prettier (or Biome's formatter, presumably).

My fear with Biome is missing out on type-aware lints, but I know Oxlint has had some success integrating the new Go typescript compiler, so maybe that will work out for Biome as well.

Replacing something hard to setup with something buggy is a win?

They've improved, and they will be fine pretty soon.