Hacker News Reader

Comment by nicoburns | Hacker News Reader

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.

View on HN

Do you have any examples where prettier code is much less readable? I haven't really ran into that issue and have been very happy with prettier.

A good example from further down the comment section:

Prettier doesn't break template literals, but it will break non-literal sections of template strings. For example, if we wrote this:

    const foo = `aaaaaaaaaaaaaaa${bbbbbbbbbbbbb}ccccccccccccccc${ddddddddddd}`;

prettier would fix it to

    const foo = 
      `aaaaaaaaaaaaaaa${
        bbbbbbbbbbbbb
       }ccccccccccccccc${
        ddddddddddd
       }`;

Which is not only much harder to read in it's own right, but now takes up 6 lines instead of one!

I have a PR fixing that: https://github.com/prettier/prettier/pull/15209

Just needs another maintainer's stamp.

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.

dprint is soo much better (configurable) and already written in Rust so very fast

I am sad it's not getting more popular

In those situations I make use of comments to force new lines where I want them. Stupid but it works!

Disable it! (https://prettier.io/docs/en/ignore.html)

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 the fix is to disable prettier for an entire file, you're proving your parent poster point.

It doesn't have to be disabled for the whole file, you can annotate lines too as shown in the link the parent commenter shared.

Adding comments just to fight with prettier is... uglier. I rather just not use prettier at all. It's more harmful than good IMO.

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.

Add a comment anywhere in the destructuring and it will force each property onto its own line.

Have you tried the print width option: https://prettier.io/docs/en/options.html#print-width?

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!

> and messes with semantics - it will add or remove parentheses in math expressions

Wait, so prettier rewrites code incorrectly? Aka, it’s buggy?

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.

No thanks.

Reformatting in precommit is destructive.

Agreed! I'd go so far as to say that we would be better off if Prettier was never created.

I wish it were more opinionated.

It treats new lines as significant in a lot of its formatting

I also don't understand their stand about curly braces. They don't add or remove them. I think they should make it uniform.

There is a plugin for that: https://github.com/JoshuaKGoldberg/prettier-plugin-curly

That's bizarre. They add/remove parens...but not curly braces...

How do you even justify that...

Curly braces are reflected in the AST, parens are not.

Reply on news.ycombinator.com