Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Prettier rock solid?

mrmr.io

Post reply on HN
Print view View original

131–140 of 163 posts

Re: Why is Prettier rock solid?

#131

Post by ravenstine »

brailsafe wrote: post #39

Meh, people seem to have an inflated view of Prettier. I find that it's at best ok, but has produced enough frustrating errors that I just turn it off.

Formatting is extremely overrated. It's important, don't get me wrong, but developers today seem to have this fetish for having a bunch of formatting rules on top of a litany of linter rules, as if the number of problems solved scales linearly with the amount of guard rails added. A level of it is useful, but so much of it is a waste of time and can lead to idiotic situations where things conflict or override one another. Not to mention time wasted bikeshedding this stuff.

Prettier, to me, is about as average as these tools come. It's not particularly offensive, though I don't understand why it's not way faster than it is.

Re: Why is Prettier rock solid?

#133

Post by samatman »

globular-toast wrote: post #86
matsemann wrote: post #71

Earlier quoted context omitted.

And autoformatters have cemented my preference for non-white spaced languages. As you say, just write whatever and let it format it. When I then switch to our python backend this strategy no longer works. Like, it can fix something, but it needs a much cleaner state to do so. For instance if my loops are indented wrong, black can't solve that as the decision it makes has a semantic meaning.

I'm amazed people are using editors that require manually tweaking indentation. I mean, apart from making sure the code is in the right block.

In languages which don't use indentation semantically, I always end up catching a bug, sooner or later, by running code through a formatter. It's usually in a complex tree of nested if statements, some code I thought was part of one group gets moved to be in another group, making it obvious where the mistake was.

Python can't do that. It's one of a few things about the language which is "nice" when using it for simple tasks, but which makes more complex programming pointlessly error-prone.

Re: Why is Prettier rock solid?

#134

Post by junon »

I don't resonate with this. We've had a bunch of annoying issues with Prettier making code a mangled mess. It's not hard to not break code syntactically, but prettier has certainly messed things up visually before.

Re: Why is Prettier rock solid?

#135

Post by sph »

mattrick wrote: post #45
deepfriedrice wrote: post #29

Earlier quoted context omitted.

1.1k open issues. OOF

1.1k isn't bad for a project with ~33 million weekly downloads[1], imo. Yes, I know that's not necessarily a good metric, but it's ~10 million more than React[2] which also has a similar number of open issues[3]. [1]: https://www.npmjs.com/package/prettier [2]: https://www.npmjs.com/package/react [3]: https://github.com/facebook/react

A code formatter has no business having 1100 open issues (5k closed). It is not rocket science.

In my experience, the number of open issues not only correlates with popularity, but how crappy the language is. Javascript projects, with its myriad of dependencies and attracting junior, inexperienced devs, tend to accumulate a great number of bugs.

For reference, curl has 24 open issues (4k closed), it is a couple orders of magnitude more complex AND more used than prettier.

Re: Why is Prettier rock solid?

#136

Post by hardwaregeek »

chubot wrote: post #69
hardwaregeek wrote: post #3

Ehh I would disagree here. Yes, prettier uses the classic pretty printing paper, but almost every pretty printer does in some form. And even then it’s subjective how you compile the actual syntax down to the printer elements. Prettier uses a very thick layer of complicated translation rules to get the printing just right. Especially with JSX and TypeScript. It’s honestly just good old testing and labor that makes it…

I think I agree about the testing and labor of complicated translation rules. But it doesn't appear that almost every pretty printer is based on the Wadler algorithm. It seems like MOST of them are not? e.g. clang-format is one of the biggest and best, and it has a model that includes "unwrapped lines", a "layouter", a line break cost function, exhaustive search with memoization, and Dijikstra's algorithm: https://ll…

Ah that’s a good point. The Dart one is the Wadler one with modified terminology, but the rest do appear to be different

Re: Why is Prettier rock solid?

#137

Post by donatj »

mgraczyk wrote: post #47

Interestingly, prettier just made a breaking change in a patch release and refused to undo it for a week or so, until a particularly silly pedantic argument won them over. https://github.com/prettier/prettier/issues/15942 My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)

I don’t see this as a breaking change. Period.

The tsconfig.json files tsc itself generates and parse are definitionally JSONC. TypeScript config files are JSONC. TypeScript itself via `tsc --init` creates a file absolutely loaded with comments.

It’s clearly the other tools that can’t handle JSONC that are the broken part. They can’t handle configs that typescript itself generates.

The contract for “breaking” here isn’t between the tool and every single poorly written tool in existence. It’s between Prettier and the config file, and it’s correctly encoding the config file.

Re: Why is Prettier rock solid?

#138

Post by nojvek »

Anything rock solid has a well thought out architecture, where the author(s) have thought through the entire problem domain and edge cases. Also has a ton of test cases to verify behavior.

Prettier is rock solid but compared to rust based tools like ruff, it is dog shit slow.

Re: Why is Prettier rock solid?

#139

Post by resters »

mcpeepants wrote: post #129
resters wrote: post #73

Earlier quoted context omitted.

A team I'm doing some work with uses eslint and has not configured prettier, so instead of simply having everything get formatted correctly, I get red squiggly lines under blocks of code because of an omitted meaningless whitespace character. There are a few linting rules that can help identify semantic errors or dead code, but only a small number of rules are needed to get all of the benefits. Autoformatting (pretti…

many (most?) red squiggles are autofixable with eslint. I use eslint exactly like prettier, in that I never think about formatting and everything gets fixed/formatted on save.

Many are, but some of the "errors" are not helpful while code is in progress. Why do I need to see them while typing if they can be easily auto-fixed later? It's just more useless visual clutter to worry about.

Re: Why is Prettier rock solid?

#140

Post by resters »

kitschpatrol wrote: post #125
resters wrote: post #73

Earlier quoted context omitted.

A team I'm doing some work with uses eslint and has not configured prettier, so instead of simply having everything get formatted correctly, I get red squiggly lines under blocks of code because of an omitted meaningless whitespace character. There are a few linting rules that can help identify semantic errors or dead code, but only a small number of rules are needed to get all of the benefits. Autoformatting (pretti…

You can mellow the squiggles for stylistic errors in VS Code. Take a look at the “eslint.rules.customizations” key in this file: https://github.com/antfu/eslint-config/blob/main/.vscode/set...

Thank you! I had been wondering if that was possible. Do you know if it can be done only for a single project / directory?
Post reply on HN