Speed is always welcome, but I just wish prettier was a little less opinionated. Specifically around line length, it will just not leave my formatting alone. I find prettier formatted code much less readable than unformatted code, and this isn't a problem I have with other code formatters like rustfmt.
Prettier often makes code written using sequences of .chaining much more difficult to read by forcing it all to the same line.
For the same reason, it often makes code written using composition more difficult to read since it won't let you decide when to put a sub-call on its own indented line for clarity.
I had the same gripe, and recently tried switching to dprint. It is much less aggressive with changing where lines break, and honestly it’s a huge relief to be able to break lines wherever I think makes the code most readable. It’s also significantly faster than prettier. I’ve been very happy with it.
I do this occasionally, and especially with things like test tables. Linters/formatters are there to help in the common case, not to be some oppressive dogma.
If I don't remember wrong, doesn't it put object destructurings on one line if they fit? That's both less readable than putting each destructured member on its own line as well as a cause of unnecessary whitespace changes in your commit history if you ever add one more field to the destructuring that takes it over the line length limit.
Yes, but unlike most formatters where the width option is a maximum and it mostly leaves your code alone below that width, prettier will aggressively widen your code to fit if you up the print width setting.
I think rustfmt will actually also widen code you have put newlines in sometimes. But it's heuristic is somehow much better than prettier's.
I think the real issue with prettier is that it's almost become a de facto standard. E.g. personally I don't like it at all, but do like Svelte, and Svelte's official (and AFAIK only) formatter uses prettier. Hence I use prettier for Svelte, and ditto for a few other things.
So the whole "extremely opinionated, if you want configuration go somewhere else" is great in principle, when people are choosing to use the tool. But if it becomes the only option for certain swathes of users, a touch more configuration would really be appropriate.
To use the Go language's formatter and a saying, "Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." That is, you may not like the style, but it's preferable over having no tool ensuring consistent style.
Agreed, but that's a different conversation because gofmt is a lot less opinionated than prettier. Prettier goes well beyond style issues, and messes with semantics - it will add or remove parentheses in math expressions, add or remove linebreaks within lines of code, etc.
If prettier worked more like gofmt I'd probably love it and have no complaints!
No, by semantic information I mean information that's meaningful to humans but not to the JS engine. E.g.:
// before prettier
var matrix = [
1, 0, 0,
0, 1, 0,
0, 0, 1,
]
var result = (num % divisor) | bitmask
// after
var matrix = [1, 0, 0, 0, 1, 0, 0, 0, 1]
var result = num % divisor | bitmask
No difference in actual behavior, but the linebreaks and extra parens were there to indicate the developer's intent, not to affect behavior.
Prettier's outlook is that this is intentional, and the developer should add "// prettier-ignore" comments to every line of code that has semantic information they want preserved.
I've never seen it be buggy, but it will often remove unnecessary parens. For example: (a * b) + (x * y) becomes a * b + x * y.
This the same code, but I often use parens for semantic grouping or to be 110% sure the operator precedence is correct for a particular formula. It's not a dealbreaker, but it does remove some of the meaning I was trying to imbue on the code.
Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice.
Besides that, I get the impression being a universal standard is kind of a non-issue for Prettier:
- If it was widespread, but highly configurable, that increases friction when switching projects, because there will be tiny formatting differences everywhere
- If it was not widespread, it would not be well known, increasing friction for users entering a project where it was used
> If it was widespread, but highly configurable, that increases friction when switching projects
This is clearly not true. Far and away the single most contentious JS style issue is ASI, and prettier has a config option for it and nobody bats an eye. Ditto for the prototypical style issues of indent size and tabs/spaces.
The value of prettier is enforcing a consistent style within a repo, and config options don't affect that. To the contrary, config options are part of why prettier is so popular - if they'd never added ASI then a lot of projects would never have adopted it.
> Well, this bounty is just about the only way that the Prettier team could contribute to solving that issue, so rejoice.
Erm, that bounty was for the production of a program that behaves exactly like prettier in at least 95% of cases, as far as I understood what "prettier test suite" means.
If it was widespread but slightly more configurable, how would that increase friction? It’s still always setup to run automatically and transform your input to the output. The whole point of it is you don’t have to think about its rules, just code and it will do the rest.
There's a more insidious side effect to prettier related to the line length thing which I'm not sure other commenters touched upon, and the reason I avoid opinionated formatters.
Prettier will affect your diff in ways you didn't intend to.
Remove a member from a destructuring assignment that brings it below the line length limit, and suddenly your diff is +1/-5 instead of 0/-1, making it slightly more difficult for your reviewer to see what the exact difference is between those 5 lines removed and 1 line added - it's not immediately clear which member was removed.
You try to rewrite a previous commit to fix a typo using Git's interactive rebase, and now the next commits won't replay on top if it because Prettier decided to reformat an entire code block.
Another fun thing to try with prettier: add a precommit hook that runs prettier, and then try to stage partial file changes.
