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

81–90 of 163 posts

Re: Why is Prettier rock solid?

#81

Post by pjerem »

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.

Prettier real usefulness is in team projects.

At $PREVIOUS_WORKPLACE, it totally removed the burden of formatting issues in PRs.

It’s far from perfect but at least everyone in the team was producing the same style and we could focus on logic errors rather than formatting (which is the first thing you spot and can’t ignore when doing a code review).

Re: Why is Prettier rock solid?

#82

Post by bowsamic »

talkin wrote: post #72
mgraczyk wrote: post #64

Earlier quoted context omitted.

https://github.com/prettier/prettier/issues/15942#issuecomme... I sort of misspoke, the comment itself is not silly, just the fact that it was that point that got a resolution.

The more silly[1] comments are from the maintainer, saying you should update configs with workarounds for patch releases. 1: Suggested package: sillier.

I looked through some of the more commented on issues and there are a lot of instances from silly and aggressive suggestions from the maintainers. I get that they're burnt out but sadly I see this kind of thing quite often on OSS projects: people have very real concerns and reasonable suggestions, and are met with the most jaded and burnt out responses possible.

Re: Why is Prettier rock solid?

#84

Post by sph »

talkin wrote: post #72
mgraczyk wrote: post #64

Earlier quoted context omitted.

https://github.com/prettier/prettier/issues/15942#issuecomme... I sort of misspoke, the comment itself is not silly, just the fact that it was that point that got a resolution.

The more silly[1] comments are from the maintainer, saying you should update configs with workarounds for patch releases. 1: Suggested package: sillier.

"It's not my commit that it is wrong, it's the rest of the world that needs to fix their code."

This is such an insane position to take for a maintainer. Don't be idealistic and silly. If you break compatibility, it is on you. No one cares that you are right.

The Linus Torvalds "we do not break the user-space, ever" mantra should be a best practice for every open source programmer, and user-space in this case is "what the rest of the world is doing".

Re: Why is Prettier rock solid?

#85

Post by sakjur »

withinboredom wrote: post #54
xrisk wrote: post #50

Earlier quoted context omitted.

Is that because they don’t use a bot to auto-close issues like a lot of other projects?

That annoys the crap out of me. Closing stale issues doesn’t make the issues go away, it just means that edge cases aren’t addressed. If I have an issue and find myself in a stale-closed issue, I’m not even going to bother reporting it. I’m either going to look for a different library altogether, one that actually tries to solve edge cases; or I’m going to create my own library as a big middle-finger to the project.…

And arguably we’re where we are because people have this idea that issue counts are comparable between projects.

I see this way of thinking around CVEs too. I think it’s a mistake of making data-driven decisions based on noise rather than signals. It sounds good when you have a comparative number to go on.

Re: Why is Prettier rock solid?

#86

Post by globular-toast »

matsemann wrote: post #71
nonethewiser wrote: post #33

Earlier quoted context omitted.

Yeah it’s true. Its not simply that you don’t have to manually format things a certain way. You simply don’t format things at all. You can avoid writing lots of spaces, newlines, semi colons, etc. it’s absolute garbage, then you save it, then it’s fine.

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.

Re: Why is Prettier rock solid?

#87

Post by globular-toast »

nine_k wrote: post #49
ozim wrote: post #40

Earlier quoted context omitted.

But I am quite happy with it I don’t have to waste my time typing. I don’t have to waste my time improving my raw typing speed. I do solid touch typing 60WPM writing plain text. With code completion and linting it easily goes twice as fast writing code.

That's cool. I'm unironically interested, how do you manage to think at such speed?

Programming is mostly thinking interspersed with a bit of typing. Nobody thinks as they type. The typing bit is just getting your abstract idea of what the program should do into the computer.

Re: Why is Prettier rock solid?

#88

Post by oreilles »

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)

How can a person that introduces breaking changes in patch release and then just says everyone to piss off when facing critics (just because mister "has needs for this": https://github.com/prettier/prettier/issues/15553#issuecomme...) be a maintainer of such a widespread tool ?

Re: Why is Prettier rock solid?

#90

Post by Mawr »

Huh? An autoformatter is just a one big pure function, so it's easy to test. It'd be odd for it not to be solid.

If it's not even fast, then nothing of note was even achieved. Anybody can write a slow formatter that conforms to a test suite.

Post reply on HN