Live data from Hacker News

Why is Prettier rock solid?

mrmr.io

91–100 of 163 posts

Re: Why is Prettier rock solid?

#91
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.…

Yeah, I stopped reporting issues to projects when I have seen tons of stale bot closed issues. Those were real bugs, still really in the codebase, just no one fixed it for arbitrary short time.

Re: Why is Prettier rock solid?

#92
post #84
post #72

Earlier quoted context omitted.

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 "wha…

Bad initial designs then will forever doom any project, if only the project has a few users. And there are lots of bad designs in the open source world and in the programming projects world in general. Especially so in the NPM and Python ecosystems. In many widespread tools.

Re: Why is Prettier rock solid?

#93
post #85

Earlier quoted context omitted.

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.

I see open issues as a pretty good signal that people are using the software and people care about its development, but maybe the number of contributors is too small. In these cases, I might even open the PR myself. Issues without replies though is probably the worst signal you can send as a maintainer. Closing issues without replying and letting a stale bot passively aggressively close issues is probably tied, but it’s usually hidden away.

Re: Why is Prettier rock solid?

#94

My complaint--and MDN and the W3C's complaint--with it is that it puts a closing slash on HTML void elements. While this is allowed for backwards compatibility with XHTML, it is not specified as being useful or needed in any HTML specification and has led to countless confusion among noobs who don't read the specification and only follow online articles. https://html.spec.whatwg.org/dev/syntax.html#start-tags

The closing slash is mandatory for jsx/tsx - and thus, most React devs - though.

That has nothing to do with HTML.

Re: Why is Prettier rock solid?

#95

My complaint--and MDN and the W3C's complaint--with it is that it puts a closing slash on HTML void elements. While this is allowed for backwards compatibility with XHTML, it is not specified as being useful or needed in any HTML specification and has led to countless confusion among noobs who don't read the specification and only follow online articles. https://html.spec.whatwg.org/dev/syntax.html#start-tags

I kind of hate that. Why have variation in the grammar based on what tag is used?

Always using `` or `` is so simple and easy.

Re: Why is Prettier rock solid?

#96
post #49
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?

I'm ~120WPM and a vim user, and yeah the main thing is how little time I actually spend typing. It helps me keep my focus on what I'm doing.

I think other tools (like the ones people are mentioning) do stuff like this for people: autocomplete, copilot, formatters, etc. I also use formatters and linters, and my autocomplete is "be strict about conventions, look up the actual meanings of words", which makes me touchy about conventions haha.

Re: Why is Prettier rock solid?

#97
Prettier was inspired by gofmt.

But I really wish gofmt gets inspired by prettier and automatically breaks long (80+ columns) lines into smaller lines (For example, move parameters of a long function each into their row).

Re: Why is Prettier rock solid?

#98

Earlier quoted context omitted.

Take a look at Biome formatter and linter. Blink of an eye fast on very large projects that prettier feels like forever on. Just don't enable the experimental or potentially breaking format options on a large existing code base. They aren't enabled by default. Deno's in the box trolling is pretty nice as well. YMMV of course.

No HTML support… bummer. I’ve been looking to switch from Prettier but I haven’t yet found a viable alternative.

You might like dprint.

Re: Why is Prettier rock solid?

#99
post #19

Earlier quoted context omitted.

For example, the latest Prettier makes XHTML files invalid by changing DOCTYPE to lowercase: https://github.com/prettier/prettier/issues/15476 Prettier moves ts-ignore comments which can cause TypeScript errors: https://github.com/prettier/prettier/issues/15876 Interpreting nested CSS functions' "-" as minus and inserting a space: https://github.com/prettier/prettier/issues/15369

1.1k open issues. OOF

I don't know enough about prettier. But in general linters (which have overlap with formatters but aren't the same) have a lot of issues that fall in the "this is not my preference. It must therefore be changed" category.

"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." I guess.

Re: Why is Prettier rock solid?

#100

Earlier quoted context omitted.

You're right, I more meant that if you don't format, your code sometimes becomes difficult to read and you become disincentivized to fix anything because git blame will point at you. I run into this all the time when people tell me, don't format the code because we won't know who did what. I get this even from senior devs as if using git blame and history is rocket science. If everyone stops bickering and just format…

If that's really an issue just reformat the whole code base once and be done with it.

Yep, plus you can always do a git blame of the commit just before this happens.

For example

  git blame a1b2c4 -- foo.js
Where a1b2c4 is the commit hash. Could even tag the commit to make it more convenient:

  git tag beforeRefmt a1b2c4
  git blame beforeRefmt —- foo.js
and push the tag up for everyone to have access to it

  git push —-tags
Post reply on HN