Hacker News Reader

Comment by haburka | Hacker News Reader

This isn’t actually true. Prettier does break code in strange circumstances and it can be very difficult to fix. The maintainers have a ton of stress on them and it’s hard to improve it sometimes.

It’s very well tested and easy to add cases too - just add an input and an output so that may be why it seems so solid, just whenever there is an issue people fix it.

I think the main thing is that Meta maintains it which probably is why it’s so solid.

View on HN

Yeah I think having motivated and paid maintainers helps a lot. If maintaining the repo is the responsibility of a team that’s working 9 to 5, it’s much more likely that it’s going to succeed. Such a project avoids most of the pitfalls that are faced by individual open source developers coding in their spare time - lack of funding, appreciation, time, help etc. If one person in the team wants to move on, the company will find another person to take their place.

That’s possibly why React and Go and Prettier continue to flourish. While the maintainers have had a lot of hard technical problems to solve, they didn’t need to worry about making rent or burning their weekends triaging issues instead of spending time with family. Many of the original authors are no longer working on the projects, but they’ve been replaced by other Google and Meta employees. This had a bigger impact than basing Go on a paper written by a Haskeller.

All this to say - if you’re depending on open source you need to fund it directly. Dont expect that FAANG will forever, or there will be a magic wand like a research paper that makes it automatically easier to maintain.

What’s an example of Prettier breaking code?

The biggest issue I run in to is with Django HTML. It's unusable. They know about it and they said they won't fix it.

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

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.

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. At work, I’ll just open a new issue, which will probably just be ignored.

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.

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.

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.

I don’t want to post a specific issue without doxxing myself but you can browse through the open issues on GitHub to find some.

Some are years old! I think the more popular languages tend to be better supported so you probably don’t know about it but prettier is a massive monolith with support for many languages and use cases. Sometimes there are bugs that mangle code

Another example: https://github.com/prettier/prettier/issues/187

That issue has been open for 7 years.

The removal of the parentheses does not change the behavior of the program. I guess that would not be considered "breaking" the code.

Reply on news.ycombinator.com