61–70 of 163 posts
> note that gofmt doesn't indent, which is the hard part interesting because for me it's hard to read changelogs of js/ts based repos that are using prettier compared to go repos, I wonder if the indentation is a reason for that. I'm honestly not sure what the author means by that either, gofmt seems to fix indentation for me.
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.
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)
> until a particularly silly pedantic argument won them over. Which comment are you referring to? The release notes sound practical
I sort of misspoke, the comment itself is not silly, just the fact that it was that point that got a resolution.
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?
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?
Earlier quoted context omitted.
I can't remember the last time PR comments addressed minor formatting issues at all, in any language. If something is hard to grok it usually has to do with logic, not if there's a space between `if` and `(`.
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…
This is the criterion for "rock solid"? I don't think a formatter has ever broken my code (in any language) and I'd be absolutely livid if one did.
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…
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://llvm.org/devmtg/2013-04/jasper-slides.pdf
The YAPF Python formatter is based on this same algorithm - https://github.com/google/yapf
The Dart formatter used a model of "chunks, rules, and spans" - https://journal.stuffwithstuff.com/2015/09/08/the-hardest-pr...
It almost seems like there are 2 camps -- the functional algorithms for functional/expression-based languages, and other algorithms for more statement-based languages.
Though I guess Prettier/JavaScript falls on the functional side.
I just ran across this paper that includes a nice survey (on lobste.rs) and it seems to cover the functional pretty printing languages influenced by Wadler, in the functional style (e.g. for and in Racket or Haskell), but not the other kind of formatter ("Google" formatters perhaps)
above a would cause the block at the bottom to become duplicated on save.
Weird as, and I couldn’t be bothered troubleshooting, I just added the file to .prettierignore. But still.